News for hackers. Stuff that matters.
Re:SQLite Release 3.42.0 by stusmall on Tuesday May 16, 2023 @10:52AM (#35962695)
Huh, I'd never thought twice about that. What would native datetime support in JSON get you that a ISO 8601 string doesn't?
Re:SQLite Release 3.42.0 by dspillett on Tuesday May 16, 2023 @11:09AM (#35962904)
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

Re:SQLite Release 3.42.0 by masklinn on Tuesday May 16, 2023 @12:08PM (#35963843)
> You might as well ask what native numeric or boolean support offer over just jamming stuff in a string in an agreed format.

A big difference is that a numeric or a boolean are quite limited datatypes with agreed upon semantics (mostly).

> Others will point out that JS doesn't have a native date/datetime/time type

It does, in fact. And it's absolute shit.

> but JSON is used for a lot more that persisting JS structures at this point.

So what I'm reading here is that you don't need types to be supported natively in order to serialize to JSON.

Re:SQLite Release 3.42.0 by dspillett on Wednesday May 17, 2023 @03:47AM (#35972373)
> It does, in fact. And it's absolute shit.

Maybe it is "just us", maybe it is part of the general shitness you point out, maybe it is the lack of literal representation (even VB and relatives had one) other than an ISO8601 string, but dates don't feel native like simpler types, arrays, objects, fictions, …

> So what I'm reading here is that you don't need types to be supported natively in order to serialize to JSON.

Yes. But not absolutely needing something does not mean it isn't (or wouldn't be) exceptionally useful to have.

Re:SQLite Release 3.42.0 by regularfry on Tuesday May 16, 2023 @11:11AM (#35962938)
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.
Re:SQLite Release 3.42.0 by 8organicbits on Tuesday May 16, 2023 @11:48AM (#35963496)
> It is a conformant subset of the ISO 8601 extended format.

Huh, TIL.

https://www.rfc-editor.org/rfc/rfc3339

Re:SQLite Release 3.42.0 by masklinn on Tuesday May 16, 2023 @11:06AM (#35962861)
Well one thing it could get you (probably wouldn't, but could) is symbolic timezones, as ISO 8601 only supports offsets.