Hacker News Reader

Comment by ilamparithi | Hacker News Reader

Another experience with NameCheap. It was April 2014. I got a domain expiry notification mail from them. I just saw that subject. The date mentioned was 4/6/2014. I am lazy and procrastinate a lot. So I saw the subject and decided that I'll renew later as I have two more months. On 6th April I got the message that my domain expired. Then I realized it was not Jun 4th as I originally thought. Not only the domain was expired, all the config details were lost. Luckily it was only entries pointing to Linode. So I quickly renewed the domain and added the entries. Still there was a considerable downtime and panic. I think companies which operate internationally should use unambiguous date formats. (Even if I had opened the email, I wouldn't have interpreted the date in any other way. It was the same format everywhere. I did give a feedback to them. Not sure whether they changed it or not).

View on HN

US date format deserves a special place in hell under any circumstances.

Seriously. It's the best here in Canada where there is no consistent convention between Euro-style or US-style dates. Officially Canada uses Euro-style dates, but we're so intertwined with the USA that it's basically random.

yyyy-MM-dd or die.

It's definitely random.

I remember having to fill a Canadian form (govt.) that had three date formats(in the same form), i.e.:

dd-mm-yy

mm-dd-yy

yy-mm-dd

In other words, make RFC 3339 mandatory for everyone internationally. And everyone has to add time zone info to dates, or just use UTC (marked as such).

I don't think the European dd-mm-yyyy is any better, since there's no way to tell whether it's April 6 or June 4. yyyy-mm-dd is the only way to go.

d-m-y at least has the logic of the number scales being in order, though if you add the time in the usual place (after) this falls down.

UK here, and unless otherwise specified I write dates in yyyy-mm-dd. That order just makes sense: it is unambiguous (well, usually, see below) and sorts nicely in string form.

One extra annoyance I've experienced is SQL Server: if your user language setting is set to "English (British)" instead of just "English" (and by "English" they mean "use American standards where there is a choice"), as well as switching which way it interprets strings of the form NN-NN-NNNN it also switches how NNNN-NN-NN is read so it expected YYYY-DD-MM. This makes no useful sense at all, as far as I know no one in the world uses YYYY-DD-MM for anything... (of course what should be done for string->date conversion is explicitly calling CONVERT() with the code for ISO8601 instead of letting it guess your string format, that was it always gets it right, but in code not controlled by us there are occurrences of just throwing the string at CAST() or letting it be implicitly cast and letting SQL Server guess the format)

04-06-2014 is the 4th of June. 06-04-2014 is the 6th of April.

I can get this right every time without learning every date parrot fashion, so there must be a way to tell.

I'm not sure how largest -> smallest component (exclusive of any more fine grained units) is any more logical than smallest -> largest.

Largest->smallest is the order the digits in the components are written in, so doing the larger structure the same way as the smaller components is more consistent.

yyyy-mm-dd is only more unambiguous (as opposed to internally consistent) than either dd-mm-yyyy or mm-dd-yyyy because there is no other common 4-2-2 digit combination, while both of 2-2-4 digit combinations are common enough that ambiguity, especially with an international audience, is certain. yyyy-MMM-dd (with month name or name abbreviations) is probably the least ambiguous (even slightly better than ISO 8601 on that point), but its also language-dependent, which is a big downside, and doesn't sort well as a string (which is a downside in automated applications, though perhaps not as much for human reading).

ISO 8601 isn't perfect, its just better than most of the alternatives and adopted as an international standard.

You "get it right" because that's the only format you see wherever you're from. It reality, it's impossible tell without context, which is why both are inferior formats.

yyyy-mm-dd has the additional benefit of being sortable as text, so it's better than dd-mm-yyyy even if you ignore the obvious ambiguity.

> I think companies which operate internationally should use unambiguous date formats.

Yeah, if only there was an international standard that addressed that...

There is, it's called ISO 8601:

http://en.wikipedia.org/wiki/ISO_8601

Also:

http://xkcd.com/1179/

I assumed on HN that ISO 8601 would be well known, that was the point.

Reply on news.ycombinator.com