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

191–200 of 284 posts

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

#191

Post by jonathrg »

VanCoding wrote: post #37
qcoret wrote: post #32

Earlier quoted context omitted.

All Temporal objects are easily (de)serializable, though. `.toString` and `Temporal.from` work great.

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.

The JSON types are string, number, boolean, null, object and array. So how could the suggested code possibly work? Do you want JSON.parse to do arbitrary code execution like Python's pickle?

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

#193

Post by tacticus »

nchmy wrote: post #125
WorldMaker wrote: post #89

Earlier quoted context omitted.

Slower to implement new features, but still implementing them, just makes it the new Firefox. IE's larger problem was how popular it had been before it stopped implementing new features. It was like if Google got bored with Chrome and decided to stop all funding on it. People would be stuck on Chrome for years after that investment stopped because of all the Chrome-specific things built around it (Electron, Puppeteer…

> Right now the world needs a lot more Safari and Firefox users complaining about Chrome-only sites and tools than it does people complaining about Safari "holding the web back". There wouldn't be Chrome-only sites and tools if Safari wasn't holding the web back (no "quotes" needed, as that's precisely what they're doing). > Safari's problems are temporary. What are you talking about? They've been woefully behind for…

> There wouldn't be Chrome-only sites and tools if Safari wasn't holding the web back

Given the number of chrome-only sites that block firefox and not safari i think there are other issues in front end land

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

#194

Post by nulltrace »

VanCoding wrote: post #31

A big step in the right direction, but I still don't like the API, here's why: Especially in JavaScript where I often share a lot of code between the client and the server and therefore also transfer data between them, I like to strictly separate data from logic. What i mean by this is that all my data is plain JSON and no class instances or objects that have function properties, so that I can serialize/deserialize i…

The serialization thing is real but I don't think OOP vs functional is the actual issue here. JSON has no date type, period. You JSON.stringify a Date, get an ISO string, and hope whoever's parsing remembers to reconstruct it. Temporal doesn't fix that part, but at least when you do reconstruct you're saying "this is a ZonedDateTime" vs "this is an Instant" instead of everything being one ambiguous Date object.

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

#195

Post by sfink »

Vinnl wrote: post #148

> Whilst Firefox was able to implement Temporal as it was being specced - thanks to the great work of André Bargull (known online as Anba) It's worth highlighting that André is actually a volunteer contributor who managed to implement the whole thing by themselves.

Considering how prolific anba is, the only way we know he isn't an LLM is because he'd have to be several generations more advanced than the current SOTA. (It is possible that he might be an LLM from a few decades in the future, considering the connection to Temporal.)

anba implemented all of Temporal single-handedly, plus fixed up numerous places in the spec, plus migrated the implementation over some massive changes after other implementers discovered what a monster it all is. The original version of the spec kind of forced two separate internal implementation paths for everything, one for custom calendars and one for the built-in stuff, just to make the built-in one reasonably performant. That was a lot of work to implement, and a lot of work to remove. (I think ptomato shepherded the spec side of that?)

Fortunately, anba knows how to take a break, relaxing occasionally with minor tasks like rewriting large swathes of the JIT code generator to optimize the support on various platforms. He also gets plenty of nutrition, by ingesting entire specs and mind-melding with them.

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

#197

Post by jitl »

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?

its gotta become bytes somehow

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

#198

Post by afiori »

Bratmon wrote: post #100
flyingmeteor wrote: post #52

Earlier quoted context omitted.

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...

Having to provide a complete schema of your json everywhere your json gets parsed negates the advantages of json.

{"$temporal_type":"PlainYearMonth","$data":"........"}

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

#199

Post by hdjrudni »

usefulcat wrote: post #178
throwaway_12629 wrote: post #174

Earlier quoted context omitted.

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();

Sorry, sleep returned a Promise and you didn't await it. You called foo() immediately.

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

#200

Post by jitl »

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.

there are a zillion of these "json pro" kind of things: superjson, devalue, capnweb, all with slightly different ideas about how to lower high-level semantics to json's available types. it's so easy to do this kind of thing, its a real https://xkcd.com/927/ situation.

CBOR (Concise Binary Object Representation) has JSON-like semantics with type extension support; with built in type extensions its much easier to get some agreement about registering certain magic type IDs to mean certain things. for example from a random google search for "cbor datetime" https://j-richter.github.io/CBOR/date.html; there's an IANA registry of type IDs: https://www.iana.org/assignments/cbor-tags/cbor-tags.xhtml

however, it is binary.

Post reply on HN