Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

It's not a slight advantage if you've ever had to parse through logfiles by hand or debug APIs with curl--it's a great deal more than that.

Why not, let's have some more examples:

In PHP (with a bug, because PHP is stupid and doesn't handle decimal fractions):

  $dateTime = DateTime::createFromFormat( DateTime::ISO8601, '2009-04-16T12:07:23Z');
In C#:

  DateTime time = DateTime.Parse("2010-08-20T15:00:00Z",  null, DateTimeStyles.RoundtripKind);
In Python (stupid that it isn't in the standard library, see https://wiki.python.org/moin/WorkingWithTime):

  import dateutil.parser
  dateutil.parser.parse('2008-08-09T18:39:22Z')
In Perl: my $dt = DateTime::Format::ISO8601->parse_datetime( "2008-08-09T18:39:22Z" );

~

Interchange formats, say JSON blobs over a wire, should very clearly express what's in them, perhaps by using a very well-known standard which is human-readable, whenever possible. The fact that some languages haven't yet realized that this is an important-enough feature to put in their standard libraries compared with whatever esoteric academic shit they think is necessary (C++1x, for example!) is not the format's problem.

Hint: if you're consuming a web API, you are probably using one of the languages I gave examples for, or a very close relative. Just because your Haskell-on-M68k package doesn't know how to 8601 doesn't mean that using a nondescript number is a good idea.

Why, in the year of our Lord 2014, is this even a fucking question?

EDIT:

I'm sorry to be so mean in my language about this, but I've had to fight a lot of raging stupid with regards to storing timestamp data. I do not wish to see anyone else suffer unduly.



> It's not a slight advantage if you've ever had to parse through logfiles by hand or debug APIs with curl--it's a great deal more than that.

Funny you should say that, UNIX time works great for log files. Since now even a dumb tool can search for values in the range, 1388491199-1420027199 to see all 2013-2014 lines.

Your way requires specific support for the date format, dealing with "2014" false positives, or searching through all 12 months individually (2013-01, 2013-02, 2013-03, etc).

You keep drumming on about library support, which is important for a format which isn't universally supported. Fortunately for UNIX time there's no value in listing them off one by one, you can just assume it is all of them...

UNIX timestamps are also listed in several international standards. Including POSIX.


ISO-8601 is designed to be sortable lexicographically, so the same benefit stays there when using dumb tools.

Again, no benefit to not using it, other than you are scared of strings. If you are handling JSON from a web API, you are already dealing in strings.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: