5 ms·
Not ES directly, but you know what I need on an almost daily basis? A JSON date type. It’s obnoxious to have to pass a string back and forth and parse it on eit
by IgorPartola 7y ago
Not ES directly, but you know what I need on an almost daily basis? A JSON date type. It’s obnoxious to have to pass a string back and forth and parse it on either end between server and browser.
- BillinghamJ 7y agoThere's plenty of good reasons one doesn't exist. JSON is not JS-specific. It is a standard interchange format used by thousands of languages, many of which have very different date implementations. If you did have a JSON date, how would you decide what it was? Would it be a timestamp, or a civil date-time? Would it have timezones? Offsets? Locations? Would there be a database along with it required to understand it correctly? Just stick with ISO8601 strings.
- ryanbrunner 7y agoA 'date' type could be as simple as syntax indicating that a particular ISO8601 string IS a date. Right now, there's no reasonable way to infer that unless you're already aware of the schema of the JSON object you're receiving. You could make the same argument with numbers - there's no reason you couldn't just pass strings containing the number - but there's advantages to being able to distinguish between a string and a number when the schema is unknown.
- BillinghamJ 7y agoIf you're not aware of the schema, how would you use the value? Same as any other use of strings - enums, types, etc
- goto11 7y agoThat is not a good reason though. The spec could just decide on the wire format like with strings and numbers, and clients would have to translate into the date type of the language or platform. The reason JSON doesn't have dates is simply because JavaScript doesn't have date literals. You can write new Date(...) in JavaScript, but allowing that in JSON would have opened a whole can of worms.
- BillinghamJ 7y agoJSON started already having incompatibilities with JS literals - JS objects are only just being made a superset of JSON in ES2019
- paulddraper 7y agoWhy have a JSON number? Why not "just stick with" decimal strings?
- dwaltrip 7y agoI see your point, but numbers are easier to standardize than dates, so there is some logic to drawing the line there. It has to be drawn somewhere.
- paulddraper 7y ago> numbers are easier to standardize than dates Is this a joke? JSON numbers are....I don't know what they even are. JavaScript -- the originator of JSON -- can't support 64-bit integers in JSON. Nor can it support decimal fractions in JSON, despite JSON using decimals. And yet JSON numbers also aren'ty IEEE-754 floating point numbers, as they lack +/-Infinity and NaN. JSON numbers are ill-defined and unique from every other "number" concept in any language or format.
- mikece 7y agoI was going to ask a variant of that question: what is the status of BigInt and when might it clear TC39 approval? In most languages a Date object is just a BigInt with Unix time() making this somewhat obvious. BigInt will allow not only proper Date implementation but Currency and Real types, and many more things.
- manigandham 7y agoBigInt is already in several modern browsers: https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/BigInt https://developer.mozilla.org/en-US/docs/Web/JavaScript/Refe...
- dmit 7y agoIf by BigInt you mean an arbitrary-precision integer type, then AFAIK no major language uses it to represent dates. If you mean a 64-bit integer type (which, to be fair, is 11 bits larger than what JavaScript supports), then that's still not enough. As long as you want nanosecond-level granularity, and range beyond the current decade for your timestamps, you'll need more than 8 bytes to represent them in code.
- wongarsu 7y agoI would argue dates with nanosecond granularity are of limited usefulness. In almost all use cases millisecond granularity is sufficient for dates, if you need nanosecond granularity chances are you also want a monotonic clock instead of real time that's subject to daylight savings, NTP correcting the clock etc.
- dmit 7y agoI think it's mostly a usability tradeoff. If you can use the same data type for calendar appointments and high-precision performance logging, then you save your users the necessity of choosing between different types. Bonus points for being able to get away with a single nanosecond-based Duration type that has straightforward arithmetic with nanosecond-based timestamps. And if you're deep enough to worry about the cost of those extra bits, you probably want to have your own date type anyway, tuned for your exact problem.
- manigandham 7y agoYou can use an unix epoch (seconds or milliseconds from 1/1/1970) to make parsing very fast. This is naturally supported by Javascripts new Date() too.
- sixbrx 7y agoits ok for instants but not dates: receiving side may truncate the instant to a date in a different timezone env than the sender (easily done and will NOT be UTC by default in many envs) -and then you may have an off-by-one on the day.
- manigandham 7y agoUnix epoch by definition is UTC. An instant can be converted properly to any timezone without issue.
- sixbrx 7y agoThat's not the point, the point is an instant is not a date. And common ways of getting the date from an instant are likely to give you the date of the instant interpreted in your current timezone for your computing env (which is often what is wanted such as when displaying for a user), so when you extract the date portion, it is not the intended one. So it's not that there's an easy right way of doing it, of course there is - but there are also easy wrong ways which also seem obvious. Also, forget about the receiving side, you're also assuming that the sending side meant the date for the instant as at offset 0 instead of in their own timezone (which is probably how the instant is being displayed for them). From experience, that's not a safe assumption - witness any instant meant to mean "today's date here and now" derived from a now() call alone or truncated to have 0 time parts (in current time zone!) - I see that attempted a lot. Way too error prone especially when you don't control both sides.
- manigandham 7y agoYes it is. An instant expressed as a Unix epoch is a date in UTC. The sender converts any non-UTC date to UTC and then to unix time. The receiver parses unix time to a UTC date, and then converts to any timezone necessary. What's the problem? If you're using code that doesn't know how to handle UTC or converts it automatically to some server/env timezone, or doesn't check the timezone of the dates then that's a problem with that code, and has nothing to do with JSON or unix time.
- tiborsaas 7y agoYou don't need to parse when getting data, the fetch API does that for you automatically. const res = await fetch(url); const data = await res.json(); For posting you do need JSON.stringify(data), but I never thought of it as painful, just a single line.
- capableweb 7y ago> fetch API does that for you automatically It does not do it automatically. Even in your example, you call `Response.json()` to do the parsing. If you change that to `Response.text()` it will be text instead. If you don't include the `.json()` call, nothing will be parsed from the body.
- tiborsaas 7y agoI know how it works :) Since it's part of the API getting a response object is pretty effortless, which is a better word than automatic, agree.
- agumonkey 7y agoClojure devs tried to make something like that with edn and transit IIUC
- vbezhenar 7y agoI was going to argue with you, that there are plenty of useful types. Temporal types are just one of them and requiring a dedicated syntax might be overkill. But now I thought more about it and honestly temporals are the most frequently used data type for interaction between systems outside of basic ones. So actually it would make a lot of sense. It could be just ISO-8601 literal. Something like `{"date": 2019-12-15, "timestamp": 2019-12-15T23:49:55.123456, "time": 19:57, "timestampwithtz": 2019-12-15T23:49:55.123456-06:00}`. It starts like a number but follows a dash or twocolon which indicates that it's not a number, but a temporal value. Should not be a problem to parse.