Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Temporal: The 9-year journey to fix time in JavaScript

bloomberg.github.io

Post reply on HN
Print view View original

171–180 of 284 posts

Re: Temporal: The 9-year journey to fix time in JavaScript

#171

Post by akdev1l »

TimTheTinker wrote: post #151
sheept wrote: post #146

Earlier quoted context omitted.

I disagree: this is not unlike including the schema in the JSON itself. This should be handled by the apps themselves, since they would have to know what the keys mean regardless. If you do want the interchange format to be the one deserializing into specific runtime data structures, use YAML. YAML's tag syntax allows you to run arbitrary code inside YAML, which can be used for what you want.

I'm not talking about something arbitrarily extensible or compound values like vectors or lat/lon. Just a few more common data types -- primitive-like values that frequently need to be passed around. This would probably best exist as a well-known wrapper around JSON itself.

Amazon ION is kind of this?

Few people seem to use it outside of Amazon tho

Re: Temporal: The 9-year journey to fix time in JavaScript

#172

Post by Manishearth »

frde_me wrote: post #170
jayflux wrote: post #108

Earlier quoted context omitted.

This was an intentional design decision. We wanted to make sure all the temporal types could be serialize/deserializable, but as you mentioned, you couldn't implicitly go back to the object you started with as JSON.parse doesn't support that. Instead the onus is on the developer to re-create the correct object they need on the other side. I don't believe this is problematic because if you know you're sending a Date,…

So it's intentional to make people pass down raw strings versus making the communication safe(er) by default?

.... we're talking about serialization here. "convert to a raw string" is sort of the name of the game.

It's a string in a well specified string format. That's typically what you want for serialization.

Temporal is typed; but its serialization helpers aren't, because there's no single way to talk about types across serialization. That's functionality a serialization library may choose to provide, but can't really be designed into the language.

Re: Temporal: The 9-year journey to fix time in JavaScript

#174

Post by throwaway_12629 »

wesselbindt wrote: post #162

I'm very happy about this. The fact that Temporal forces you to actually deal with the inherent complexities of time management (primarily the distinction between an instant and a calendar datetime) makes it incredibly difficult to make the mistakes that Date almost seems designed to cause. It's a bit more verbose, but I'll take writing a handful of extra characters over being called at 3AM to fix a DST related bug a…

Technically, you're not likely to to have to fix a DST bug at 3AM any day but Sunday.

Re: Temporal: The 9-year journey to fix time in JavaScript

#175

Post by WorldMaker »

Dragory wrote: post #101
WorldMaker wrote: post #77

Earlier quoted context omitted.

> What I don't understand is why they had to make string formatting so rigid. Maybe it has to do with internationalization? I'd have liked if it included a sort of templating system to make the construction of rendered date-time strings much easier. I think Temporal takes the right approach: toString() is the (mostly) round-trippable ISO format (or close to it) and every other format is accessible by toLocaleString()…

The problem is that sometimes you want a very specific format, not a locale-based format. This currently still has to be implemented in userland [1]. [1] https://github.com/js-temporal/proposal-temporal-v2/issues/5

A lesson I've picked up from what little localization work I've done is to avoid "specific formats" as much as possible. Some user's locale is never going to fit your "specific format" and the more you try to (micro-)manage the output format of your dates the more you are likely to make that user upset or show them a very broken experience. The short/medium/long formats you can get out of Intl.DateTimeFormat/toLocaleString aren't perfect, they are compromises, but they work and users can generally trust them.

(If you are using a specific format for something other than display to a user, maybe consider the standardized ISO format instead. Machine-to-machine communications could definitely use a whole lot fewer "specific formats" and explicit Date parsing. Very few backend languages don't have out-of-the-box support or easy found library support for ISO format today.)

Re: Temporal: The 9-year journey to fix time in JavaScript

#176

Post by foresterre »

flyingmeteor wrote: post #52
VanCoding wrote: post #37

Earlier quoted context omitted.

That's not what I mean. Even though it is serializable, it's still not the same when you serialize/deserialize it. For example `JSON.parse(JSON.stringify(Temporal.PlainYearMonth.from({year:2026,month:1}))).subtract({ years: 1})` won't work, because it misses the prototype and is no longer an instance of Temporal.PlainYearMonth. This is problematic if you use tRPC for example.

You would need to use the `reviver` parameter of `JSON.parse()` to revive your date strings to Temporal objects. As others have said, it's a simple `Temporal.from()` https://developer.mozilla.org/en-US/docs/Web/JavaScript/Refe...

Depending on your needs (i.e. how you would otherwise use your output jspn), using the reviver can have a significant impact on performance. JSON.parse itself is hyper-optimized. At the company I work we used the reviver for almost exactly this, but profiling showed that using the reviver had enormous impact on performance. We cut it out, and won in the seconds of performance for some large json's.

Re: Temporal: The 9-year journey to fix time in JavaScript

#177

Post by plastic041 »

tmpfile wrote: post #160

I’d like to have interval types for example const D = new Temporal() const t = new Interval({minutes:5}) const v = D.add(t)

That's Duration!

    const D = Temporal.PlainDate.from("2020-06-16");
    const t = Temporal.Duration.from({ day: 1 });
    const v = D.add(t) // 2020-06-17
https://developer.mozilla.org/en-US/docs/Web/JavaScript/Refe...

Re: Temporal: The 9-year journey to fix time in JavaScript

#178

Post by usefulcat »

throwaway_12629 wrote: post #174
wesselbindt wrote: post #162

I'm very happy about this. The fact that Temporal forces you to actually deal with the inherent complexities of time management (primarily the distinction between an instant and a calendar datetime) makes it incredibly difficult to make the mistakes that Date almost seems designed to cause. It's a bit more verbose, but I'll take writing a handful of extra characters over being called at 3AM to fix a DST related bug a…

Technically, you're not likely to to have to fix a DST bug at 3AM any day but Sunday.

    // call foo() one day from now:
    sleep(86400); foo();

Re: Temporal: The 9-year journey to fix time in JavaScript

#179

Post by QGQBGdeZREunxLe »

Noticed that converting between certain calendars is not supported. Was that choice intentional?

    const today = Temporal.PlainDate.from("2569-03-11[u-ca=buddhist]"); 
    today.toLocaleString("en", { calendar: "hebrew" });
    > Uncaught RangeError: calendars "buddhist" and "hebrew" aren't compatible

Re: Temporal: The 9-year journey to fix time in JavaScript

#180

Post by rmunn »

QGQBGdeZREunxLe wrote: post #179

Noticed that converting between certain calendars is not supported. Was that choice intentional? const today = Temporal.PlainDate.from("2569-03-11[u-ca=buddhist]"); today.toLocaleString("en", { calendar: "hebrew" }); > Uncaught RangeError: calendars "buddhist" and "hebrew" aren't compatible

Converting between solar-based and lunar-based calendars is fraught with potential for ambiguity. The Buddhist calendar is a solar calendar, while the Hebrew calendar is lunar-based. So converting between dates in the Buddhist calendar and the international-standard (ISO 8601) calendar is typically easy (give or take some subtleties I won't go into for reasons of length). But converting between the Hebrew calendar and the ISO 8601 calendar, or the Buddhist calendar, involves figuring out when the new moon will be — and since the lunar cycle is 29 or 30 days, 12 lunar months add up to 354 days. So the lunar calendars, including the Hebrew calendar, typically add a "leap month" every two or three years in order to track the sidereal year.

All of which means there are many potential ambiguities in converting between calendars, and the combinatorial explosion possible means they probably only want you to convert between non-ISO8601 calendars and ISO8601. It would be too easy to get corner cases wrong otherwise and not notice, I'm sure. So to convert a date from Buddhist calender to Hebrew calender, you'd probably have to do Buddhist -> ISO8601, then ISO8601 -> Hebrew. (I haven't had time to test that for myself yet, I'll post a correction if that turns out to be wrong).

Post reply on HN