[staz]

all that and still no datetime support which is the most annoying thing missing in JSON imho

[stusmall]

Huh, I'd never thought twice about that. What would native datetime support in JSON get you that a ISO 8601 string doesn't?

[dspillett]

Type validation for one. The reduced chance that a client has put some backwards format in there like MM-DD-YYYY (or DD-MM-YYYY for that matter) or just an invalid date completely.

You might as well ask what native numeric or boolean support offer over just jamming stuff in a string in an agreed format. Some might argue that dates are a compound value so differ from atomic types like a number, but they are wrong IMO as a datetime can be treated as a simple numeric¹ with the compound display being just that – a display issue.

Others will point out that JS doesn't have a native date/datetime/time type, but JSON is used for a lot more that persisting JS structures at this point.

--

[1] caveat: this stops being true if you have a time portion with a timezone property

[masklinn]

Well one thing it could get you (probably wouldn't, but could) is symbolic timezones, as ISO 8601 only supports offsets.

[regularfry]

What it gets you is not having to deal with breakage when someone doesn't know the difference between ISO8601 and RFC3339 or, in fact, `date` strings. Shuffle all that mess off down the stack to where someone else has made one decision, once, rather than having to relitigate it every time.

[masklinn]

JSON will never have datetime support, since Javascript does not have datetime literals (and that's a good thing given how horrible the Date object is).

Probably more importantly, all of that and still not proper datetimes in sqlite.

Also even more so no domains (for custom datatypes).

[Mister_Snuggles]

> Probably more importantly, all of that and still not proper datetimes in sqlite.

Home Assistant recently did a ton of changes to work around the issues caused by this.

The short story is that they stopped storing timestamps as 'timestamp' datatypes and started storing them as unix times stored in numeric columns. Since timestamps turn into strings in SQLite, this was a huge improvement for storage space, performance, etc.

The problem is that this change also affects databases which have a real datetime datatype. So PostgreSQL, which internally stores timestamps as unix times, is now being told to store a numeric value. To treat it as a timestamp you have to convert it while querying. Since I used PostgreSQL for my Home Assistant installation, this feels like a giant step backwards for me.

I wish that they had used this change as an opportunity to refactor the database code a bit so that they could store timestamps as numeric for SQLite, but use a real timestamp datatype for MySQL and PostgreSQL. I'm sure that this isn't a simple thing to do though.

[flatline]

Inconsistent datetime storage has been a consistent issue for me providing cross-provider and cross-application/framework support for SQLite.

[chris-orgmenta]

In people's opinions: Would this feature be appropriate to implement, or beyond the scope of what the JSON project should aim for?

[pdimitar]

I don't know what "appropriate" or even "beyond the scope" mean in this context but, having in mind that datetime data needing to be stored is a fact of life that's not going away then I'd say yes, it does belong in JSON.

It also belongs in SQLite.

[Thaxll]

You can remove JSON, when is SQLite adding proper date type?

[thunderbong]

It's already available -

https://www.sqlite.org/stricttables.html