Hacker News Reader

Comment by stickfigure | Hacker News Reader

JSON needs to have a timestamp type. Parsers should automatically convert them to/from native language timestamp objects. Human readable is preferred, but really the critical aspect is to make the JSON self-describing. If timestamps are self-describing, any smart editor can display them properly.

View on HN

JSON doesn't have types like that so that doesn't make sense. It supports a few simple primitives and that's what makes it extensible and gives it it's power. Types like timestamps should come from the language or library that produces JSON only.

https://www.json.org/

Semantically timestamp is a product type imho, so the logical representation in JSON would be with an object: {"year" 2022, "month": 4, "day": 1, ...etc}. The fact that nobody does that and instead serialize it to ISO-style string is telling about json.

> The fact that nobody does that and instead serialize it to ISO-style string is telling about json.

Tell me more about that. I'm not sure I grasp what it is telling about JSON?

I see it as a sign that JSON is not that great for structured data if people prefer to pack their datetime structure into a string rather than the more native object format.

Oh, gotcha. Well, I definitely agree it would make more sense for it to be an object like you mentioned but I think it's probably more explainable by the fact there is native support for ISO date / time strings in most programming languages, making it just as easy to parse a date or time from a string value and having the added advantage of reducing the size of the payload on the wire. I could be wrong

JavaScript has a date type. It is perfectly reasonable to expect JavaScript Object Notation to have a date type.

Wait until you visit the link and read what “object” means in JSON, especially the part about remaining interchangeable with all programming languages

"All" programming languages have some concept of a timestamp, or at the very least can manage a coherent mapping. Adding timestamp to JSON would introduce no portability issues. It would reduce portability issues by standardizing a commonly used data type.

"My programming language doesn't have timestamps" is not a real problem.

"Ten thousand stupid date formats which are all ambiguous with either numbers or strings" is an actual problem that people bang their heads into every day.

> Adding timestamp to JSON . . .

What are you talking about? JSON is a format for exchanging data of any kind. It doesn't have types beyond a set of primitives to that it can remain as a _notation_ that allows you to pass any type you define and want to send.

Nothing is stopping any library or language from implementing an object or String for dates or times (or both) and tons of them have done so.

It wouldn't be JSON's place at all to start defining anything like that.

Nonsense. JSON (or "JSON++") can define any arbitrary primitives. Someone already made the arbitrary decision to have boolean values instead of "true" and "false" strings; having timestamps is merely another arbitrary decision.

You seem to believe that the primitives in JSON are some sort of platonically pure form. They were merely a choice, and a that choice could be improved.

CBOR has four defined timestamp formats---see https://www.iana.org/assignments/cbor-tags/cbor-tags.xhtml

.NET has no trouble going between ISO-8601 and the native DateTime type.

If you have a priori knowledge of the schema (say, mapping to/from classes) you can convert anything. You don't even need something like JSON, you could just have a binary format and IDL.

JSON self-describes booleans, numbers, strings, arrays, objects, and null. This is especially convenient when working with dynamic or ambiguous structures, and working in dynamically typed languages. Timestamp is sufficiently common and useful that it should be added to that list.

If you mean ".NET parser pattern matches strings and converts them dynamically" - that's the same horrible behavior yaml parsers have and it causes endless trouble. Imagine parsing titles of posts and some clever author makes a title that matches the timestamp format.

The .NET parser will only parse ISO-8601 to a DateTime if that's the type you tell it to accept. If you tell it to accept a string, it won't try to do anything funny no matter what that string may look like.

When .Net just started, they would deserialzie datetime to... a string which looked something like `DateTime\(2007-12-10\)`.

10-15 years later I'm still baffled by that early decision (and glad it's been fixed since then)

unixtime/microseconds is not necessarily a acute reflection for you to say what i year/month/day/hour/minute/second i am experiencing from an societal standpoint.

and that is important in realworld applications.

Reply on news.ycombinator.com