Temporal literals really deserve dedicated syntax in JSON. I'm bored to parse yet another "18.2.2020".
Check out "Falsehoods programmers believe about time": https://infiniteundo.com/post/25326999628/falsehoods-program...
I just spent 2 days programming a timezone selector in a React form that changes the displayed date/time as you switch timezones but the underlying UTC representation wouldn't change.
All this without loading 500k JS timezone libraries. I only used Intl API and tz.js [1].
The trick simply was to temporarily shift the date by the difference between the local time and the edited time zone. :)
If you're near a change in daylight savings then that will go wrong.
Really this time & timezone stuff should be handled by the OS, system calls or libs should be more sophisticated so we aren't "solving" these problems over and over again.
But I'm about to start ranting about Unicode, so I'll shut up now... ;-)
The reason I stated I'd like the generic version is that there are other types that we use consistently. There's a very nice RFC available for telephone numbers that we've started following and we can marshal/unmarshal pretty easily from strongly typed languages (where we control the code), but wouldn't it be nice if there was a standard way (within the JSON to let systems know it was a telephone number?
VSCode even has JSON Schema support built in, which is cool. I use that a lot.
If you're going to invent a new language like json-schema, you might as well skip to json2.
People who care about schemas already enforce this at the serialization layer where the objects being mapped to implicitly are the schema.
Pushing the schema down to the protocol just adds complexity and bloat.
Dynamic languages don't have an enforced schema. You can do it manually, but a schema is easier, special-purpose, declarative.
Plus, data schema languages are typically far more expressive than programming languages. e.g. java doesn't even have nonnullable (which C had, as non-typedef structs). They're closer to a database schema.
a) no mandatory quotes for dicts keys b) date and time intervals in iso 8601 format. c) optional type-specifiers for strings, so we can add e.g. ip4 and ip6 addresses. Eg. { remote: "127.0.0.1"#ip4 }
e.g. { guests: 42, arrival: @2020-02-17T17:22:45+00:00, duration: @@13:47:30 }
Any sufficiently complicated serialization technology contains an ad-hoc, informally-specified, bug-ridden, slow implementation of half of ASN.1.
Also, thingo aggressively protected JSON's simplicity, banishing comments because people were using them as parser directives.
I see JSON Schemas used all over. Advertising, Medical, Banking, etc.
ISO8601 won't scale to universe-level applications!
:)
International Atomic Time (TAI), which differs by UTC by 37 seconds since it doesn't count leap seconds, solves everything I know of. Although the clocks aren't in a single reference frame, the procedure for measuring their differences and averaging them to define TAI is well defined and so sets an objective standard for "what time is it on Earth".
JSON isn't meant to be self-describing format. There is JSON schema or the like if that is what you are after.
And yet to a very large extent, it is. Strings, numbers, booleans, arrays, and associative maps made the cut. Timestamps would be a pretty reasonable addition. It would certainly cut out all the controversy here.
Yes :)
That's the beauty of it: time is just a number (of seconds since 1 January 1970).
> Which scalar data type should your parser use?
Integer, since it's an integer number of seconds.
> And is it seconds since epoch or milliseconds since epoch?
Unix time is always seconds.
> That's the beauty of it: time is just a number (of seconds since 1 January 1970).
Having a bare number where the units and zero point rely on out-of-band information is not self-describing.
If you want something self-describing, maybe look into XML?
> Yes :)
> That's the beauty of it: time is just a number (of seconds since 1 January 1970).
> > Which scalar data type should your parser use?
> Integer, since it's an integer number of seconds.
> > And is it seconds since epoch or milliseconds since epoch?
> Unix time is always seconds.
Whilst time can indeed be modelled as "just a number", Unix time spectacularly fails to achieve even that.
* It can go backwards * Simple subtractions do not give accurate intervals
It's not a good measure of time. Don't use it as such.
Then it is a complete non-starter for "just use ______". I work on software that requires millisecond precision (honestly it would benefit from even greater precision) at the transport layer. It's not even really doing anything spectacularly complex or unusual. Seconds simply aren't sufficient for tons and tons of use cases.
Javascript time (that 'JS' in JSON) is always milliseconds.
Wasn't there a BSD that used double instead of long for time_t for a while ages ago?