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

31–40 of 284 posts

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

#31

Post by VanCoding »

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

This is not the case for Temporal objects. Also, the temporal objects have functions on them, which, granted, makes it convenient to use, but a pain to pass it over the wire.

I'd clearly prefer a set of pure functions, into which I can pass data-only temporal objects, quite a bit like date-fns did it.

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

#32

Post by qcoret »

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…

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

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

#33

Post by nekevss »

philipallstar wrote: post #30

> have to agree on what "now" means, even when governments change DST rules with very little notice. I didn't spot how Temporal fixes this. What happens when "now" changes? Does the library get updated and pushed out rapidly via browsers?

Typically time zone data is updated in IANA's time zone database. That data would need to be updated in the implementation. In this case, the browser would need to update their time zone data.

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

#34

Post by ChrisArchitect »

deepsun wrote: post #28
ChrisArchitect wrote: post #23

Aside: Bloomberg JS blog? ok.

Bloomberg has a pretty large software engineering department, including a lot of offshore contractors. Similar to Walmart Labs that does cool stuff as well, despite being part of a retail chain (retail industry typically sees SWEs a cost, not asset).

oh, just meant it was a new tech blog from them.

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

#35

Post by OptionOfT »

patchnull wrote: post #6

[flagged]

> The other half come from the implicit local timezone conversion in the Date constructor.

Outlook at that issue even in their old C++ (I think) version.

You're in London, you save your friend's birthday as March 11th.

You're now in SF. When is your friend's birthday? It's still all-day March 11th, not March 10th, starting at 5PM, and ending March 11th at 5PM.

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

#36

Post by [deleted] »

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…

[deleted]

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

#37

Post by VanCoding »

qcoret wrote: post #32
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…

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.

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

#39

Post by mrkeen »

plucas wrote: post #12

Would have been interesting to connect back to Java's own journey to improve its time APIs, with Joda-Time leading into JSR 310, released with Java 8 in 2014. Immutable representations, instants, proper timezone support etc. Given that the article refers to the "radical proposal" to bring these features to JavaScript came in 2018, surely Java's own solutions had some influence?

Yep, JavaScript got the bad version from Java too!

https://news.ycombinator.com/item?id=42816135

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

#40

Post by CharlesW »

cubefox wrote: post #19
zvqcMMV6Zcr wrote: post #17

> Safari (Partial Support in Technology Preview) Safari confirmed as IE Spiritual successor in 2020+.

2026 A.D., still no support for native date pickers in mobile Safari.

Safari for iOS got native date pickers in 2012, and desktop Safari got them in 2021.
Post reply on HN