4 ms·
JSON needs to have a timestamp type. Parsers should automatically convert them to/from native language timestamp objects. Human readable is preferred, but reall
by stickfigure 5y ago
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.
- jaywalk 5y ago.NET has no trouble going between ISO-8601 and the native DateTime type.
- stickfigure 5y agoIf 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.
- jaywalk 5y agoThe .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.
- dmitriid 5y agoWhen .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)
- deknos 5y agounixtime/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.
- softwarebeware 5y agoJSON 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/ https://www.json.org/
- zokier 5y agoSemantically 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.
- softwarebeware 5y ago> 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?
- zokier 5y agoI 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.
- softwarebeware 5y agoOh, 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
- stickfigure 5y agoJavaScript has a date type. It is perfectly reasonable to expect JavaScript Object Notation to have a date type.
- spc476 5y agoCBOR has four defined timestamp formats---see https://www.iana.org/assignments/cbor-tags/cbor-tags.xhtml https://www.iana.org/assignments/cbor-tags/cbor-tags.xhtml