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

101–110 of 284 posts

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

#101

Post by Dragory »

WorldMaker wrote: post #77
ravenstine wrote: post #50

Earlier quoted context omitted.

When I write JavaScript, I make as many things immutable as I can. Sometimes it adds verbosity and leads to less efficient computational patterns, but overall I believe I run into far fewer bugs that are hard to make sense of. There are things about the design of Temporal I don't really like, but immutability was a solid move. What I don't understand is why they had to make string formatting so rigid. Maybe it has to…

> 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

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

#102

Post by Bratmon »

sourcegrift wrote: post #81
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.

I'm excited for this conversation. If you see someone respond to a developer ergonomics complaint with "If you give me your background I'll explain in longer terms... anyone who understands s modicum of PL theory" you're about to see some legendary bullshit.

It's like witnessing a meteor shower!

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

#103

Post by Avamander »

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…

> 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

Which makes me wonder how it'll look like when interfacing with WASM. Better than Date?

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

#104

Post by kibwen »

thayne wrote: post #87
Waterluvian wrote: post #18

Earlier quoted context omitted.

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.

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

Same. I'm at the point where I feel like copy-by-default semantics are one of the ancient original sins of programming languages. Single-ownership is so, so useful, and it's trivial to implement and not at all difficult to understand (especially compared to something like Rust's borrow checker).

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

#105

Post by kibwen »

vimwizard wrote: post #27
Waterluvian wrote: post #18

Earlier quoted context omitted.

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…

Rust ownership model ("stacked borrows" I believe it's called) is basically this

Single-ownership ("affine types") is a separate concept from a borrow checker. Your language doesn't need a borrow checker (or references at all) to benefit from single-ownership, though it may make some patterns more convenient or efficient.

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

#107

Post by masfuerte »

andrewl-hn wrote: post #70
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

The only time you need local dates is for scheduling. Stuff like “Report KPIs for each shift. Shifts start at 8:00 local time.”, or “send this report every day at 10:00 local time”, or “this recurring meeting was created by user X while they were in TimeZone Z, make sure meetings follow DST”. Outside of scheduling UTC is the way.

> Report KPIs for each shift. Shifts start at 8:00 local time.

To represent this you probably don't want a local date. Plain times [1] and plain date/times [2] are a better fit.

[1]: https://developer.mozilla.org/en-US/docs/Web/JavaScript/Refe...

[2]: https://developer.mozilla.org/en-US/docs/Web/JavaScript/Refe...

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

#108

Post by jayflux »

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…

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, DateTime, MonthDay, YearMonth type from one side, then you know what type to rebuild from the ISO string on the other. Having it be automatic could be an issue if you receive unexpected values and are now dealing with the wrong types.

There is an example here in the docs of a reviver being used for Temporal.Instant https://tc39.es/proposal-temporal/docs/instant.html#toJSON

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

#109

Post by tracker1 »

patchnull wrote: post #6

[flagged]

Yeah... I pretty early in my career firmly cemented on a couple things with date-times. It's either a date-time + zone/location detail or always seconds from unix epoc or UTC in iso-8601 style (later JSON's adopted default) across the wire. Since most systems and JS convert pretty easily between UTC and local.

Same for storage details. I started using the 8601 style mostly in file/log naming so they always sorted correctly, this kind of carried over into my code use pre-dating JSON spec.

Doing the above saves a lot of headaches... I'd also by convention use a few utility scripts for common formatting and date changes (I use date-fns now mostly), that would always start with dtm = new Date(dtm); before manipulation, returning the cloned dtm.

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

#110

Post by hombre_fatal »

recursive wrote: post #14
ndr wrote: post #13

Earlier quoted context omitted.

Immutability is underrated in general. It's a sore point every time I have to handle non-clojure code.

Given the ubiquity of react, I think immutability is generally rated pretty appropriately. If anything, I think mutability is under-rated. I mean, it wouldn't be applicable to the domain of Temporal, but sometimes a mutable hash map is a simpler/more performant solution than any of the immutable alternatives.

Well, mutability is the default, and React tries to address some of the problems with mutability. So React being popular as a subecosystem inside a mutable environment isn't really evidence that people are missing out on the benefits of mutability.

Though React is less about immutability and more about uni-directional flow + the idiosyncrasy where you need values that are 'stable' across renders.

Post reply on HN