3 ms·

ISO-8601 not good enough for you? It’s a standard, human readable, has every datetime detail, every language that supports JSON can read it. What’s missing?

• tshaddox 6y ago
  Be careful ever saying “every datetime detail”! An obvious one is that ISO 8601 can’t represent the location of the local time with enough information to know the current (or historical) daylight saving time rules for that location. You might not need that now, but you might if you’re building a calendar app! ISO 8601 can represent a simple offset from UTC, but it can’t do a lot of the things that the IANA time zone database can do.
  • Swizec 6y ago
    Fair, very fair. Have gotten bit by that in the past. Adding an IANA library to the ISO8601 library (often part of the same lib) has so far solved that problem for me. I’m sure it starts struggling with dates before the early 1800’s though. Also doesn’t work well if you’re dealing with relativistic effects I think.
• ncallaway 6y ago
  I've never had a problem with dates by always serializing them as ISO-8601. It absolutely has every benefit you cite. It's the only ISO spec I know the name of without having to look it up.
  • fiddlerwoaroof 6y ago
    Is the -0700 offset PDT or MST? ISO-8601 doesn’t solve a whole bunch of problems related to locale-aware date math.
    • nly 6y ago
      Three character timezones like "PDT" also aren't good enough because they make it too easy to encode timestamps that don't make sense, like a British Summer Time (BST) time in December. To be honest I think you're better off just not encoding the timezone in your main timestamp string at all and instead adding the full IANA timezone name (e.g. "Europe/London") in to a separate field. In sensible formats all the dates within a single JSON object or object will have the same timezone anyway, and to save bytes you can simply say in your spec "If absent, assume UTC".
      • fiddlerwoaroof 6y ago
        Yeah, I'm just using the three character timezone as a handy shortcut: the point is an ISO-8601 timestring isn't unambiguous in all contexts.
• nly 6y ago
  As silly as it is, I don't use it strictly because the 'T' between the date and the time making them harder to read. "YYYY-MM-DD hh:mm:ss.nnn" and a separate timezone field is the format for me. Another problem with ISO is the specs aren't freely available, so people will generally guess or refer to old versions, drafts, or RFCs (like RFC 3339)
• Someone 6y ago
  A json parser can discriminate between the integer 42 and the string “42”, but it cannot discriminate between the date 2021-02-23T08:10:19+0000 and the string “2021-02-23T08:10:19+0000” because in json, the date 2021-02-23T08:10:19+0000 will have to be encoded in a string. That means your json parser either will accidentally parse some strings as dates, or will have to be told which strings are (or even might be) dates, introducing a partial schema, or it will have to leave it to the application to convert strings into dates. Workable? Somewhat, but not ideal, just as not supporting numbers, and leaving string-to-integer-conversion to the application (after all, JavaScript will happily convert strings to integers in eval) would be ‘not ideal’. Also, are you going to accept 2021-02-23T08:10:19Z, too? Leaving out the seconds, minutes,…? for interoperability, you would have to specify that.