4 ms·
> The problem isn't that you can't represent dates; it's that there is no standard way to do it. ISO 8601?
by _kst_ 11y ago
> The problem isn't that you can't represent dates; it's that there is no standard way to do it.
ISO 8601?
- eknkc 11y agoThat is a string. Not date.
- emodendroket 11y agoThat's not "standard." That's one of many ways that people represent dates in JSON, because the JSON specification itself does not mandate that you use any particular representation. If you use it there is no guarantee it will be recognized as a date on the other end.
- Kapow 11y agoWhat black hole are you sending JSON into where the only way they could know something is a date is if you use a date type? Why can't that be part of the data structure you agreed upon in order to communicate in the first place?
- eknkc 11y agoEven if there is an agreed on schema, parsers can generate native Date objects on the recipient if there is a date type. When you deserialize a nested graph of objects, it's hard to convert each date to an actual date if what you get is just a string. Makes it a lot easier during integration.
- emodendroket 11y agoWhy am I hand-writing code to supplement the parser? I mean, hell, we don't need JSON at all, why don't I just invent my own serialization format and write parsers for it in each environment I want to use it in.
- duaneb 11y agoWell, it'd need to cover dates, times with time zones, date times with time zones, times without time zones, date times without time zones. Seems better pegged to the data source without thinking it out clearly.
- emodendroket 11y agoSo? It's not like this is a complex problem nobody knows how to solve.
- duaneb 11y agoAgreed! But it's not so simple to just add a "date" type; it would add significant complexity to a relatively simple text format.
- emodendroket 11y agoYeah, I guess, but everyone ends up implementing it anyway; the problem is they all do it in an idiosyncratic way (and one that is ambiguous... after all, maybe I really wanted that to be a string).