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

151–160 of 284 posts

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

#151

Post by TimTheTinker »

sheept wrote: post #146
TimTheTinker wrote: post #142

Earlier quoted context omitted.

Sounds like we need an extended JSON with the express intent of conveying common extended values and rich objects: DateTime instants (with calendar system & timezone), Decimal, BigInt, etc.

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.

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

#152

Post by tshaddox »

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…

Don’t JavaScript Date instances have the same problem? Date implements toJSON, but when parsing JSON you’ll have to manually identify which string values represent Dates and convert them back to Date instances. The exact same is true of Temporal (e.g. Instant).

And as far as I know, date-fns deals with native Date instances, not “data-only objects.”

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

#154

Post by tshaddox »

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.

This is also true of JavaScript Date instances, so I’m curious what solution you had that did work with raw JSON stringify and parse.

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

#155

Post by SchemaLoad »

cityofdelusion wrote: post #133
julius_eth_dev wrote: post #116

[flagged]

Assuming this isn’t an LLM bot, I don’t see how you ship that bug multiple times. The docs for JS time are pretty minimal and it’s clear it only stores UTC epoch, so why would you assume it can handle “wall clock time” with no other context? It doesn’t matter if it’s python or tsql or JS or perl — you read the docs on the date time impl every time.

They do seem to be an LLM bot from comment history

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

#156

Post by tshaddox »

cityofdelusion wrote: post #133
julius_eth_dev wrote: post #116

[flagged]

Assuming this isn’t an LLM bot, I don’t see how you ship that bug multiple times. The docs for JS time are pretty minimal and it’s clear it only stores UTC epoch, so why would you assume it can handle “wall clock time” with no other context? It doesn’t matter if it’s python or tsql or JS or perl — you read the docs on the date time impl every time.

Good luck making sure no one ever uses a “yyyy-mm-dd” string to represent a calendar date in a JSON API, then passes the value to the Date constructor, then formats that Date in a browser. It’s an extremely easy mistake to make without very strict conventions around how calendar dates and timestamps are represented across the entire stack.

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

#157

Post by tmpfile »

hungryhobbit wrote: post #43

From the article: const now = new Date(); The Temporal equivalent is: const now = Temporal.Now.zonedDateTimeISO(); Dear god, that's so much uglier! I mean, I guess it's two steps forward and one step back ... but couldn't they have come up with something that was just two steps forward, and none back ... instead of making us write this nightmare all over the place? Why not? const now = DateTime();

Or const now = new Temporal();

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

#158

Post by wesselbindt »

cityofdelusion wrote: post #133
julius_eth_dev wrote: post #116

[flagged]

Assuming this isn’t an LLM bot, I don’t see how you ship that bug multiple times. The docs for JS time are pretty minimal and it’s clear it only stores UTC epoch, so why would you assume it can handle “wall clock time” with no other context? It doesn’t matter if it’s python or tsql or JS or perl — you read the docs on the date time impl every time.

> Assuming this isn’t an LLM bot, I don’t see how you ship that bug multiple times

I don't know about the guy you're replying to, but I've made many mistakes in my coding life, and some of them more than once. The Date API is written in a way to obfuscate the real complexities of date and time management, so I find it quite easy to imagine someone stepping in the same footgun more than once.

EDIT: oh ew, grandparent comment is a bot. How did you recognize it?

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

#159

Post by tshaddox »

hungryhobbit wrote: post #43

From the article: const now = new Date(); The Temporal equivalent is: const now = Temporal.Now.zonedDateTimeISO(); Dear god, that's so much uglier! I mean, I guess it's two steps forward and one step back ... but couldn't they have come up with something that was just two steps forward, and none back ... instead of making us write this nightmare all over the place? Why not? const now = DateTime();

That’s uglier because, if you were previously doing new Date(), you almost certainly don’t want a zonedDateTime. You almost certainly want an Instant.
Post reply on HN