6 ms·

Lack of a native date/time format in JSON has been the biggest pain point for me. Most (all?) serializers convert Dates to an ISO string but that almost always

Lack of a native date/time format in JSON has been the biggest pain point for me. Most (all?) serializers convert Dates to an ISO string but that almost always requires manual conversion back to a Date during deserialization before doing anything useful with it. Using epoch for dates makes simple math & before/after comparison easier but requires explicit conversion during serialization. Unfortunately from what I can tell, I-JSON doesn't appear to solve this problem (or does it??) One nice thing about BSON is they made Date types first class citizens of the format.

kjhughes 12y ago
One might wish for a strict requirement for date formats for better interoperability, but at least I-JSON recommends something: ISO 8601 [per RFC3339] (with additional restrictions - see section 4.3 which I've quoted elsewhere on this page).
- huherto 12y ago
  Relevant. https://xkcd.com/1179/ https://xkcd.com/1179/
  - deitcher 12y ago
    I love it. When I first started in IT (1994, don't ask...) working with London and Tokyo and San Fran and Singapore and everyone wrote dates differently. I just started writing YYYY-MM-DD everywhere, and all of the questions went away.
    - smoyer 12y ago
      Looks like ISO-8601 to me! We've standardized on using this format (extended to include time where necessary) whenever our JSON objects include a date or date/time. We've also standardized on UTC. Since our system clocks are already synchronized that way, it's easy for us and we simply i18n/l12n them on entry and/or display.
      - deitcher 12y ago
        It was, I just didn't know it at the time! I was simply looking for some way to write emails and spec docs in a way that everyone would have a common frame of reference with zero extra work. Yeah, in storage (as above), I use epoch all the way through and convert as needed. But as the thread above shows, not everyone likes this path...
- thom_nic 12y ago
  Yes, conformance to a single string representation of a datetime is nice. Unfortunately that still doesn't help the issue when deserializing, you're just going to get a string that needs to be manually converted to a Date object.
deitcher 12y ago
Dunno, I always liked storing date/time as epoch. Every language under the sun seems to have a native method for working with it. Yeah, I need to deal with de/serialization, but it is a small price to pay, no?
- pimlottc 12y ago
  Epochs don't tell you what time zone you're working with and they aren't very easy to read/debug at a glance.
  - deitcher 12y ago
    Fair enough @pimlottc. But most of the time I am far more concerned with accurately capturing a moment in time than I am with making it instantly readable. I also have helped some companies that ran into serious datetime management issues when they worked with strings that led engineers to assume a certain timezone, others to assume others, and chaos ensued. Epochs may not be instantly readable, but they do force everyone onto the same page. In any case, I tend to view a timezone as a separate piece of data than the actual moment in time (but I know others have a different paradigm): datetime = accurate moment in time; timezone = the timezone for which this should be viewed, or was captured or, etc.
    - jameshart 12y ago
      So by epoch, obviously you mean the number of seconds since Jan 1 1970. Midnight - 00:00, right? Ah... but then... UTC? or TAI? There's a 35 second difference, after all. There's a school of thought that the UNIX epoch counts from 1970-01-01 00:00:10 TAI...
      - nknighthb 12y ago
        POSIX specifies the Epoch to be UTC and has since at least 2001. People may have other opinions on how it should be specified, but if you're going to follow POSIX as it exists, you're not left with a choice in the matter. http://pubs.opengroup.org/onlinepubs/009695399/basedefs/xbd_chap03.html#tag_03_149 http://pubs.opengroup.org/onlinepubs/009695399/basedefs/xbd_...
tomchristie 12y ago
> I-JSON doesn't appear to solve this problem It's not within the scope of what I-JSON is intended to address. This is a more formally specified and slightly more constrained variation of the existing JSON spec. Adding new datatypes would mean that it would no longer be JSON.
- thom_nic 12y ago
  I'll agree there aren't many ways this could be solved without breaking compatibility with JSON. Certainly something like {"created": Date("2013-12-1T12:00:00Z")} a la BSON seems elegant but is incompatible with JSON. Maybe something like "String values that match (some computationally inexpensive ISO-8601-matching regex) shall be converted to Date instances by the JSON parser" could be possible without huge compatibility issues. I guess I was mostly using this topic to voice what I'd imagine is a common point of frustration in an otherwise great data interchange format.
  - stouset 12y ago
    No, definitely don't do that. You're just trading one set of small annoyances for a huge set of unpredictable problems.

kjhughes 12y ago

One might wish for a strict requirement for date formats for better interoperability, but at least I-JSON recommends something: ISO 8601 [per RFC3339] (with additional restrictions - see section 4.3 which I've quoted elsewhere on this page).

huherto 12y ago
Relevant. https://xkcd.com/1179/ https://xkcd.com/1179/
- deitcher 12y ago
  I love it. When I first started in IT (1994, don't ask...) working with London and Tokyo and San Fran and Singapore and everyone wrote dates differently. I just started writing YYYY-MM-DD everywhere, and all of the questions went away.
  - smoyer 12y ago
    Looks like ISO-8601 to me! We've standardized on using this format (extended to include time where necessary) whenever our JSON objects include a date or date/time. We've also standardized on UTC. Since our system clocks are already synchronized that way, it's easy for us and we simply i18n/l12n them on entry and/or display.
    - deitcher 12y ago
      It was, I just didn't know it at the time! I was simply looking for some way to write emails and spec docs in a way that everyone would have a common frame of reference with zero extra work. Yeah, in storage (as above), I use epoch all the way through and convert as needed. But as the thread above shows, not everyone likes this path...
thom_nic 12y ago
Yes, conformance to a single string representation of a datetime is nice. Unfortunately that still doesn't help the issue when deserializing, you're just going to get a string that needs to be manually converted to a Date object.

deitcher 12y ago

Dunno, I always liked storing date/time as epoch. Every language under the sun seems to have a native method for working with it. Yeah, I need to deal with de/serialization, but it is a small price to pay, no?

pimlottc 12y ago
Epochs don't tell you what time zone you're working with and they aren't very easy to read/debug at a glance.
- deitcher 12y ago
  Fair enough @pimlottc. But most of the time I am far more concerned with accurately capturing a moment in time than I am with making it instantly readable. I also have helped some companies that ran into serious datetime management issues when they worked with strings that led engineers to assume a certain timezone, others to assume others, and chaos ensued. Epochs may not be instantly readable, but they do force everyone onto the same page. In any case, I tend to view a timezone as a separate piece of data than the actual moment in time (but I know others have a different paradigm): datetime = accurate moment in time; timezone = the timezone for which this should be viewed, or was captured or, etc.
  - jameshart 12y ago
    So by epoch, obviously you mean the number of seconds since Jan 1 1970. Midnight - 00:00, right? Ah... but then... UTC? or TAI? There's a 35 second difference, after all. There's a school of thought that the UNIX epoch counts from 1970-01-01 00:00:10 TAI...
    - nknighthb 12y ago
      POSIX specifies the Epoch to be UTC and has since at least 2001. People may have other opinions on how it should be specified, but if you're going to follow POSIX as it exists, you're not left with a choice in the matter. http://pubs.opengroup.org/onlinepubs/009695399/basedefs/xbd_chap03.html#tag_03_149 http://pubs.opengroup.org/onlinepubs/009695399/basedefs/xbd_...

tomchristie 12y ago

> I-JSON doesn't appear to solve this problem It's not within the scope of what I-JSON is intended to address. This is a more formally specified and slightly more constrained variation of the existing JSON spec. Adding new datatypes would mean that it would no longer be JSON.

thom_nic 12y ago
I'll agree there aren't many ways this could be solved without breaking compatibility with JSON. Certainly something like {"created": Date("2013-12-1T12:00:00Z")} a la BSON seems elegant but is incompatible with JSON. Maybe something like "String values that match (some computationally inexpensive ISO-8601-matching regex) shall be converted to Date instances by the JSON parser" could be possible without huge compatibility issues. I guess I was mostly using this topic to voice what I'd imagine is a common point of frustration in an otherwise great data interchange format.
- stouset 12y ago
  No, definitely don't do that. You're just trading one set of small annoyances for a huge set of unpredictable problems.