2 ms·

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 rea

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.
    - angersock 12y ago
      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.
      - deleted 12y ago
        [deleted]
Someone1234 12y ago
> 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 http://store.steampowered.com/hwsurvey

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.
  - angersock 12y ago
    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.
    - deleted 12y ago
      [deleted]

Someone1234 12y ago

> 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 http://store.steampowered.com/hwsurvey