JSON: Add Datetime, Timedelta and Binary Data Types

💡 Ideas
1

Every day a lot of developers re-invent work-arounds for the fact that JSON is missing
some basic data structures: Datetime, Timedelta and Binary Data Types

I know this can't be fixed in one year. This will take several years.

How to start this journey?

1 Like
2

2 of those 3 data types you mentioned aren't things in JavaScript.

1 Like
3

And JSON isn't even part of ECMAScript, but an entirely different spec complete with an RFC. It's just an interchange format whose syntax was inspired by ES3.

You might have better luck elsewhere, and if you want anything changed, you'll need to contact a lot of different people and get several companies interested. Also, do expect resistance - part of the allure of JSON is because of its simplicity, and there's a lot of tooling built on it that would have to change.

4

Thank you for pointing me in the right direction.

I think it should be possible to make binary, datetime, timedelta optional available. Tools should only need to update if the want to use the new features.

5

as a bit of resistance:

unlike c# and other languages, a datetime datatype in javascript doesn't add much value, because in practice, javascript-programmers offload most datetime-logic to external databases (or [client-side] wasm-sqlite3).

the remaining scenarios in javascript-land are mostly i/o -- message-passing isostrings over-the-wire between UI's <-> datastores.

6

The Temporal proposal will likely change this practice, however.

7

Quoting Wikipedia: "JSON is a language-independent data format."

Python supports binary, datetime, timedelta and many other languages, too.

Why not create smooth transition with optional support for more data types? I see no drawback.

A lot of specs get continous upgrades (tcp, http, ...) why not JSON?

8

Is there already a common way to parse a string to a temporal object?

I started a little page to gather notes. I would like to add a early sketch how datetime could get serialized in JSON.

Here are the early notes: https://github.com/guettli/lets-fix-json/blob/master/README.md

9

yes, temporals are commonly created by parsing from isostrings:

var json = {
    "isostring": "2019-11-26T14:58:54.147Z"
};
var datetime = Temporal.DateTime.from(json.isostring);

what you'll find in practice is that isostrings (e.g. "2019-11-26T14:58:54.147Z") are sufficient for representing datetime in JSON, and there no need to complicate it with an additional datetime datatype.

10

I want it simpler, not more complicated.

I would like to be able to load a json string. And the data structure in the language js/python/... should be highlevel data structure. This should happen without any additional step like parsing strings or base64-decoding.

11

The issue is that dates and times are complicated, and simplifying them runs the risk of losing way too much information. They sound much simpler than they are:

  • Times could be local or have a time zone, and that's not even counting leap seconds. You can't even measure the number of seconds between two instants without reading the tzdb first.
  • Date manipulation depends on leap years (which are themselves non-trivial), and this is only assuming the civil Gregorian calendar - astronomers usually use Julian years (defined as exactly 365.25 days of 86400 SI seconds) in their calculations, and religions like Islam have their own calendars (in that case, the Islamic calendar, based on the moon rather than the sun), and so while the temporal proposal strictly focuses on the Gregorian calendar, most larger date manipulation libraries include support for other calendars like those.
  • Combine the two, and it gets even more complicated. You've got time zones (some are even like UTC+4:30), you've got daylight savings (you can't even assume this is an hour forward), you've got various governments passing laws changing either or both of these at any moment, you've got all the abbreviations like "EST" for Eastern Standard Time and "UTC" for Universal Coordinated Time, and it all gets super messy.

Separately, JSON does not have any sort of date, time, or date-time syntax, and never has. The usual way of handling it is serializing it as ISO-8601 (what you get out of Date.prototype.toJSON and Date.prototype.toISOString and deserializing it accordingly.

12

Yes, you are right. Serializing and parsing dates is complicated. But it was already solved several times and there are specs for it. I would never ever reinvent this. This is already solved.

Yes, JavaScript does not have any sort of date, time (up to now).

13

I’ve been wanting something like this for ages.

A way now writing Date literal without using new Date. So dates (and time deltas) can be transmitted and read easily.

14

Just FYI: this is most likely dead on arrival. I tried as little as just trying to get comments in, and even that wound up proving near impossible to get anywhere.

15

I like the simplicity of JSON. I don't think it's practical to try and incorporate a bunch of special-purpose data-structures into the spec. If we add support for Date, then someone will want support for a set data structure (it deserializes into the languages native set data-structure). If we add support for that, then someone will want to add support for enums.

And, what happens when the target language doesn't have a concept of a set, or an enum, or a timespan, or whatever feature we're wanting to add to JSON? As JSON is supposed to be language agnostic, I think it's important that we keep its feature set down to a minimum, because:

  • It makes it easier for any language to add good support for it.
  • It keeps parsers simple, letting this get used on, for example, IOT devices
  • It keeps the spec more stable, we're not trying to always add new features to it, causing everyone to have to update their parsers
2 Likes