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".
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.