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

81–90 of 284 posts

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

#81

Post by sourcegrift »

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

If you give me your background I'll explain in longer terms but in short it's about making the intent clear and anyone who understands s modicum of PL theory understands why what's a constant is so and what's a function is so.

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

#82

Post by WorldMaker »

bnb wrote: post #3

Can't wait for it to land in the server-side runtimes, really the last thing preventing me from adopting it wholesale.

Deno has had it behind the `--untable-temporal` flag for quite a few Minor versions now and the latest Minor update (because of TC-39's Stage 4 acceptance and V8 itself also marking the API as Stable) removed the requirement for the flag and it is out of the box.

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

#83

Post by Xenoamorphous »

Waterluvian wrote: post #18
patchnull wrote: post #6

[flagged]

The worst are methods that both mutate and return values. I know this gets into a complex land of computer science that I don’t understand well, but I wish I could define in TypeScript “any object passed into this function is now typed _never_. You’ve destroyed it and can’t use it after this.” Because I sometimes want to mutate something in a function and return it for convenience and performance reasons, but I want…

> The worst are methods that both mutate and return values

Been bitten a few times by Array.sort().

Luckily there’s Array.toSorted() now.

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

#84

Post by robpalmer »

ChrisArchitect wrote: post #23

Aside: Bloomberg JS blog? ok.

Yep. You can learn more about why we created this new blog here:

  https://bloomberg.github.io/js-blog/post/intro/
I hope you like it ;-)

And if it seems like a surprise, you can blame me for not publicising this kind of content earlier given how long we've been working in this area. Thankfully Jon Kuperman and Thomas Chetwin (plus others) found the time and energy to put this platform together.

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

#85

Post by VorpalWay »

patchnull wrote: post #6

[flagged]

It is not just in time keeping that mutable shared state is an issue, I have seen problems arising from it elsewhere as well in Python especially, but also in C and C++. Probably because Python is pass by reference implicitly, while C and C++ makes pointers/references more explicit, thus reducing the risk of such errors in the code.

There a few schools of thought about what should be done about it. One is to make (almost) everything immutable and hope it gets optimised away/is fast enough anyway. This is the approach taken by functional languages (and functional style programming in general).

Another approach is what Rust does: make state mutable xor shared. So you can either have mutable state that you own exclusively, or you can have read only state that is shared.

Both approaches are valid and helpful in my experience. As someone working with low level performance critical code, I personally prefer the Rust approach here.

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

#86

Post by rimunroe »

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.

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

I don't know if I'm missing something, but that's exactly how I'd expect it to compose. Does the following do what you wanted your snippet to do?

  Temporal.PlainYearMonth.from(JSON.parse(JSON.stringify(Temporal.PlainYearMonth.from({year:2026,month:1}))))
JSON.stringify and JSON.parse should not be viewed as strict inverses of each other. `JSON.parse(JSON.stringify(x)) = x` is only true for a for a small category of values. That category is even smaller if parsing is happening in a different place than stringification because JSON doesn't specify runtime characteristics. This can lead to things like JSON parsing incorrect in JS because they're too large for JS to represent as a number.

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

#87

Post by thayne »

Waterluvian wrote: post #18
patchnull wrote: post #6

[flagged]

The worst are methods that both mutate and return values. I know this gets into a complex land of computer science that I don’t understand well, but I wish I could define in TypeScript “any object passed into this function is now typed _never_. You’ve destroyed it and can’t use it after this.” Because I sometimes want to mutate something in a function and return it for convenience and performance reasons, but I want…

> any object passed into this function is now typed _never_. You’ve destroyed it and can’t use it after this.

That is basically what affine types are. Once the value is "consumed" it can't be used again.

In rust, this is expressed as passing an "owned" value to a function. Once you pass ownership, you can't use that value anymore.

And having used it in rust, I wish more languages had something like that.

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

#88

Post by themafia »

darepublic wrote: post #48

My playbook for JavaScript dates is.. store in UTC.. exchange only in UTC.. convert to locale date time only in the presentation logic. This has worked well for me enough that Im skeptical of needing anything else

I have a scheduling system that allows users to specify recurring events. "Every Monday at 2pm." Which needs to be understood in the native timezone of that user and needs to be capable of being displayed in that timezone for all viewers or optionally in the native timezone of the viewing user.

Temporal is a blessing.

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

#89

Post by WorldMaker »

zvqcMMV6Zcr wrote: post #17

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

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, Selenium, etc and so forth).

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". Safari's problems are temporary. Chrome is the new Emperor and IE wasn't bad because it stopped, it was bad because it stopped after being the Emperor for some time. People remember how bad the time was after the Empire crumbled, but it's how IE took so many other things down with it that it is easier to remember the interregnum after IE crumbled than to remember the heyday when "IE-only websites are good enough for business" sounded like a good idea and not a cautionary tale.

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

#90

Post by tadfisher »

deepsun wrote: post #25
patchnull wrote: post #6

[flagged]

They seem to have taken it from Joda time that revolutionized time in java 10+ years ago. Sadly no mention of Joda.

Also no mention of Stephen Colebourne, author of Joda and the JSR-310 spec (the basis of java.time), the one person you should always stop and listen to when he says you are doing something wrong with time.

Alas, this post is not the only time the TC39 people ignored him.

Post reply on HN