Sometimes in security, and life in general, it’s the seemingly small issues that cause problems.  As the saying goes, “The devil is in the details.”

Take dates for example.  If I were to suggest we meet for a 10:00 coffee on 07/10/09, when should you show up?  Most of you would assume that 09 is 2009.  Then you’d hope to infer from other information whether I meant July 10th or October 7th.  Those who know I’m a night owl might wonder if I mean 10 p.m., while my old army buddies would assume that if I meant 10 at night I’d write 22:00.

About ten years ago, software developers and IT managers were in hectic race against the clock. In many cases they just didn’t know what would happen when computers using two digit dates rolled from 99 to 00.  Or 100. And it appears  that in the past 10 years we’ve learned very little about standardization.

Of course there are those who don’t bother with the year at all.  The yogurt in my fridge reads JL13.  At least I can figure out that they mean July 13, and I can hope that this container didn’t somehow get shoved to the bottom of the pile for a year.  Or even worse, the dreaded “Best before 08/01.” Is it good for another month and a half, or should I carefully double bag it and put it in the trash without disturbing whatever new life form might dwell beneath the lid? It just doesn’t make sense to force product manufacturers to put a date on something if we can’t be positive what it means.

Fortunately there is a simple solution:  Adopt the international standard, ISO 8601. Unlike many ISO standards, it isn’t all that complex.  June 22, 2009 is 2009-06-22 or 20090622.  10:00 a.m. is 10:00:00, and 10:00 p.m. is 22:00:00. Provisions exist for omitting seconds, etc., if they aren’t required.

Isn’t today a good date to become part of the solution?