4 ms·

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/201

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

JonoBB 12y ago
US date format deserves a special place in hell under any circumstances.
- Pxtl 12y ago
  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.
  - bushido 12y ago
    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
  - tempodox 12y ago
    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).
- psychometry 12y ago
  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.
  - cs02rm0 12y ago
    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.
    - dragonwriter 12y ago
      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.
    - psychometry 12y ago
      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.
  - dspillett 12y ago
    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)
dragonwriter 12y ago
> I think companies which operate internationally should use unambiguous date formats. Yeah, if only there was an international standard that addressed that...
- babuskov 12y ago
  There is, it's called ISO 8601: http://en.wikipedia.org/wiki/ISO_8601 http://en.wikipedia.org/wiki/ISO_8601 Also: http://xkcd.com/1179/ http://xkcd.com/1179/
  - dragonwriter 12y ago
    I assumed on HN that ISO 8601 would be well known, that was the point.

JonoBB 12y ago

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

Pxtl 12y ago
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.
- bushido 12y ago
  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
- tempodox 12y ago
  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).
psychometry 12y ago
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.
- cs02rm0 12y ago
  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.
  - dragonwriter 12y ago
    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.
  - psychometry 12y ago
    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.
- dspillett 12y ago
  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)

dragonwriter 12y ago

> I think companies which operate internationally should use unambiguous date formats. Yeah, if only there was an international standard that addressed that...

babuskov 12y ago
There is, it's called ISO 8601: http://en.wikipedia.org/wiki/ISO_8601 http://en.wikipedia.org/wiki/ISO_8601 Also: http://xkcd.com/1179/ http://xkcd.com/1179/
- dragonwriter 12y ago
  I assumed on HN that ISO 8601 would be well known, that was the point.