A date with sanity

I would like to refer you back to the second video clip on ‘We are what we do‘, the one entitled ‘Arctic Death Spiral and the Methane Time Bomb’. It’s a bit long by today’s go-faster standards: well over an hour. Time well spent, I suggest. In fact, if you haven’t already seen it, your time would be better spent watching that than continuing to read my feeble drivel.

Now, on to the point of this post…

There are several places within ‘Arctic Death Spiral and the Methane Time Bomb’ that feature dates, at the lower right. For instance, at time 58:39 there is a legend ‘3/6/13′.

Clearly, the ’13’ refers to 2013 — just a baker’s dozen years after we learnt what a mistake it was not to store years as four digits. So short, our attention span: we’ve forgotten the millennium bug lesson already.

But, it’s worse than that.

These dates are associated with clips from other video footage, and there is no way to be sure whether the date format used in those clips is month/day/year (which USAns and others will assume) or day/month/year (which Brits like me, and others, will assume). The date ‘3/6/13’ could thus be either 06Mar2013 or 03Jun2013 ^[1]. So much for data accuracy in scientific material.

My main point, though, is this: if we cannot even agree upon a universal date format, what chance have we of co-operating on anything more important?

Homo fatuus brutus strikes again.

---

^[1] A long time ago — well, for me, anyway: and, as it happens, in a galaxy that resembled this one but was very, very different — during my early interactions with these new-fangled computer thingies, I taught myself BASIC (beginner’s all-purpose symbolic instruction code). My first computer was a ZX Spectrum; my second was an Amstrad PCW (personal computer word-processor).

Why am I waffling on about this? I’m getting to it…

There was a magazine dedicated to the PCW, ‘8000 Plus’, that ran a regular feature showcasing BASIC programs that were written in just ten lines of code. I toyed with the idea for some time before coming up with such a program of my own, in 1986: I called it ‘valiDATE’. I recall struggling to coerce the mass of code into the requisite ten lines, and the sense of achievement when I finally succeeded. Sadly, I no longer have a copy of the program (such is the fleeting nature of digital memory).

What valiDATE did was accept any date in any format and convert it into what I call ‘UUDF’: universally unambiguous date format. UUDF is ‘nnMmmyyyy’; ie two digits for the day, three letters representing the month (the first upper case, the next two lower case) and then — anticipating Y2K — a four-digit year. UUDF has the benefit of a fixed length (any date from 01Jan0001 through to 31Dec9999 is just nine characters) and it features inbuilt separation of the three fields, by virtue of the switch from numeral to letter and back again.

It’s true that from 1988 we’ve had the option to use ISO 8601 — which has many advantages, but to my mind the biggest downsides with that standard are a) it’s hard to read and b) it offers too many choices which overcomplicate it; YYYY-MM-DD or YYYYMMDD; YYYY-MM but, importantly, not YYYYMM (so as to try to avoid confusion with the ‘truncated form’ YYMMDD — though the attempt fails because that format is still used, and there are similar conflicts with the very common DDMMYY and MMDDYY, albeit that separators are often used in those).

Unsurprisingly, nobody at the ISO asked me for my opinion when they were deciding on the ISO 8601 standard. There is, of course, absolutely no reason why they should as I’m just another grunt; though if they had I might have tried to argue that UUDF is more legible than an all-numeric code, and that, while it might seem that only using the digits 0-9 might make data entry easier, what it really does is makes it more error-prone because it’s all too easy to enter a wrong digit and not realise it.

Oddly enough, I came across this very problem just this past week: I had entered ‘12022010’ instead of ‘12122010’. The error there is easily overlooked: and yet the difference between ’12Feb2010′ and ’12Dec2010′ is immediately obvious.

I do grant you that I had made the mistake of using a dash of parochial thinking in my design of UUDF; I had neglected to consider that those whose first language is other than English will have different names for each of the months. But even so, catering for all such differences is infeasible, and English, by dint of Old Empire (and the linguistic laziness of your average Brit) is more common across our world than almost all other languages.

Given the unlikelihood of our calendar system being changed anytime in the near future, what’s needed is twelve short, unique alphabetic labels, and, though these could be chosen from any language, the set Jan/Feb/Mar/Apr/May/Jun/Jul/Aug/Sep/Oct/Nov/Dec is as good as any and better than many.

For instance: consider the UUDF 01Apr2014. The same date is commonly expressed in a multitude of different ways. In ISO 8601 it could be either (!) 2014-04-01 or 20140401. In fact I often use the latter when naming computer files because of the automagical-date-sort-on-name feature. Alternatively, you can take your pick from many other formats, including 1.4.14, 4/1/14, 1st April ’14, April 1 2014, 1 April 2014… and, of course, All Fools’ Day.

Yes, I chose that date for this example for good reason. We are all fools. I say again: if we cannot even agree upon a universal date format, what chance have we of co-operating on anything more important?