4 ms·

Why do you have all the times in Unix time instead of ISO-8601 UTC? EDIT: Also, the "about" value in the users api appears to be truncated. Compare... https:/

Why do you have all the times in Unix time instead of ISO-8601 UTC? EDIT: Also, the "about" value in the users api appears to be truncated. Compare... https://hacker-news.firebaseio.com/v0/user/angersock# https://hacker-news.firebaseio.com/v0/user/angersock# ...with... https://news.ycombinator.com/user?id=angersock 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.

Someone1234 12y ago
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-unix-timestamp-to-datetime-and-vice-versa https://stackoverflow.com/questions/249760/how-to-convert-un...
- angersock 12y ago
  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.
  - teach 12y ago
    That's two programming languages. Not all languages have a nice ISO-8601 parser built-in. Human-readable is a slight advantage, agreed.
    - angersock 12y ago
      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 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.
      - Someone1234 12y ago
        > 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.
- unfunco 12y ago
  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.
  - Someone1234 12y ago
    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.
sararob 12y ago
[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.
- angersock 12y ago
  Ah, cool. There was no warning of that fact--maybe you could add that?

Someone1234 12y ago

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-unix-timestamp-to-datetime-and-vice-versa https://stackoverflow.com/questions/249760/how-to-convert-un...

angersock 12y ago
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.
- teach 12y ago
  That's two programming languages. Not all languages have a nice ISO-8601 parser built-in. Human-readable is a slight advantage, agreed.
  - angersock 12y ago
    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 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.
    - Someone1234 12y ago
      > 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.
unfunco 12y ago
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.
- Someone1234 12y ago
  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.

sararob 12y ago

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

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