There is a great old saying that the marvellous thing about standards is that there are so many of them…. and things don’t get much worse than date and time formats. Are we using DD-MM-YY or MM-DD-YY or DD-MM-YYYY… I could go on for some time, nothing sets my teeth on edge more than not being certain what date format I am looking at.
What amazes me is how many consumer oriented application still don’t respect regional time settings or use a common standard. I recently evaluated CrashPlan for instance as an alternative to DropBox. I was fairly surprised to find that the CrashPlan logs were all in USA date format (even though I am using the CrashPlan Australia portal).
The good news is that there a common standard for date stamps that some IT vendors are now sticking to, which is called ISO 8601. A date stamp in ISO 8601 format always uses YYYY-MM-DD. A great example of a log file that follows this standard is the vmware.log file of any Virtual Machine:
There is a great write-up of the format and structure for ISO 8601 here: http://www.cl.cam.ac.uk/~mgk25/iso-time.html
So why do I care about date formats (and why should you?). The answer is error logs.
In todays IT world no system is an island. There is always interaction. When you want to understand root cause you need to understand event order. If you cannot trust the time stamps (because NTP is not in use and the timezones are wrong) and you cannot combine the logs (because the time and date formats are wildly different), then you are in trouble. So next time you are evaluating a solution, scare your vendor and ask if they support ISO8601. Tell them to get on board.
This brings us to the three rules of time management (the three laws of the Time Lords):
- Always co-ordinate your time.
- Always get your timezone correct.
- Always use a standard time and date format.
And remember… there is only person who can break the laws of time: