Also, never set jobs to run at midnight (00:00) as nobody will be able to tell what day it is. Set it to 00:01 or something.
And tbh, don't run jobs on the hour anyway. Everything kicks off then. Set stuff to run at 01:45 or 02:15 or something instead.
(None of these suggestions are time change related)
In general I try to use odd times for cronjobs. Backups starting at XX:13, analysis scripts at XX:23, data exports at XX:42 and so on. This simplifies the question of "Why does my system go whack at 23:23? Oh, wait".
With enough precision in your timestamp, you can base-10 encode arbitrary binary data and shove it in your nanos for debugging.
This is a great tip. One of our QA engineers noticed recently that a particularly difficult-to-reproduce bug was affecting records saved at :21, which is when a particular cronjob hits. Without that extra info we’d probably still be scratching our heads over it.
That's a good idea.
Honestly haven’t seen 00:00 cause confusion outside of “dog ate my homework” scenarios. If you’re using 12h clock then clearly it’s a bigger issue.