EDIT: Also, the "about" value in the users api appears to be truncated. Compare...
https://hacker-news.firebaseio.com/v0/user/angersock#
...with...
https://news.ycombinator.com/user?id=angersock
EDIT2: Note that the JSON is correct, but the preview in the firebase API seems to be broken.
EDIT3: No issue tracker on the Github? Laaaame.
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...
There are very few good reasons to choose a Unix timestamp to represent a date when compared with ISO-8601.
> 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.
var time = new Date("<ISO-8601 string>") // in Javascript
time = DateTime.iso8601("<ISO-8601 string>") # in Ruby
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.
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.
Human-readable is a slight advantage, agreed.
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');
DateTime time = DateTime.Parse("2010-08-20T15:00:00Z", null, DateTimeStyles.RoundtripKind);
import dateutil.parser
dateutil.parser.parse('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.
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.
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.