UNIX time is actually much easier to parse and more accurate. Almost all platforms (even Windows[0]) have a way to convert a UNIX time into a culture specific local time.

What you're asking for is a string you have to parse. That's a lot more work and there is a lot more that can go wrong.

[0]https://stackoverflow.com/questions/249760/how-to-convert-un...

How is it more accurate? ISO-8601 allows for leap seconds, it uses the same second counting frequency as the Unix timestamp, it can represent dates before 1970 and after 2038 (64-bit Unix timestamps will also.) and it's an international standard.

There are very few good reasons to choose a Unix timestamp to represent a date when compared with ISO-8601.

When UNIX is converted into the local culture leap seconds are added (along with time zone, daylight savings time, et al), defining dates before 1970 is irrelevant (and also untrue, UNIX times can be negative), and as systems are moving rapidly to 64 bit the 2038 deadline will be irrelevant (e.g. my Chrome AND their server software are both 64 bit already).

> There are very few good reasons to choose a Unix timestamp to represent a date when compared with ISO-8601.

Complete lack of string parsing is a good one.

Um, how about, no?

  var time = new Date("<ISO-8601 string>") // in Javascript

  time = DateTime.iso8601("<ISO-8601 string>") # in Ruby

Aaaand it's human readable! Aaaaand it works before the Unix epoch!

EDIT:

Changed DateTime.parse to DateTime.iso8601, to be even more retentive.

Look, parent claimed that parsing ISO strings is hard (it's not, especially if you're consuming a web api on a modern web language) and that it was more readable (which is so clearly wrong I have no words).

As for being more accurate, again no. The range is worse (lol wraparound if you're using a 32-bit int), there isn't explicit support for fractional seconds, doesn't map onto UTC cleanly, doesn't handle leap seconds, and so on.

It's only "easier" if you don't actually care about a human-readable timestamp that is robust and if you desire to do date parsing yourself instead of using any of the well-established libraries out there. Ugh.

> and that it was more readable (which is so clearly wrong I have no words).

I never claimed that. In fact I didn't address readability at all. So I have no words for your "no words" relating to a claim that literally didn't appear at all.

> The range is worse (lol wraparound if you're using a 32-bit int), there isn't explicit support for fractional seconds, doesn't map onto UTC cleanly, doesn't handle leap seconds, and so on.

Fortunately we're already well on our way into a 64 bit world, and aside from legacy systems it won't be a problem by 2038. According to the Steam hardware survey [0] over 80% of Windows machines, 100% of OS X machines, and 90% of Linux machines are already running a 64 bit OS.

Leap seconds can be handled during the cultural conversion.

> It's only "easier" if you don't actually care about a human-readable timestamp that is robust and if you desire to do date parsing yourself instead of using any of the well-established libraries out there. Ugh.

I don't care about human readable timestamps for an API used in automation. More robust is subjective, particularly as parsing it is more technically complex (particularly as most of the parsers support several different but similar DateTime formats).

Most well-established libraries support UNIX time natively or use it internally.

[0]http://store.steampowered.com/hwsurvey

That's two programming languages. Not all languages have a nice ISO-8601 parser built-in.

Human-readable is a slight advantage, agreed.

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.

[Firebase Dev Advocate] @angersock - the "about" value you're seeing on the Firebase Dashboard isn't broken, it's just a truncated preview. The HN team is using email for issues, so you can send them any feedback at api@ycombinator.com.

Ah, cool. There was no warning of that fact--maybe you could add that?