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

71–80 of 284 posts

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

#71

Post by WorldMaker »

OptionOfT wrote: post #35
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.

If your friend lives in London it may be useful to have that associated timezone so that you can be sure to message them that day in their timezone. They might better appreciate a message from SF sent on March 10th at 9PM "early that morning in London" than March 11th at 9PM "a day late".

A lot of that gets back to why Temporal adds so many different types, because there are different uses for time zone information and being clear how you shift that information can make a big difference. (A birthday is a PlainDate at rest, but when it is time to send them an ecard you want the ZonedDateTime of the recipient's time zone to find the best time to send it.)

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

#72

Post by idle_zealot »

goatlover wrote: post #42
wiseowise wrote: post #24

Earlier quoted context omitted.

> convention Is the keyword. Anything that should never be broken isn’t a convention. There’s no better convention than compiler error.

Because Ruby is a dynamic language which mutates state. That isn't considered wrong or bad in those kinds of languages, just a way to make sure the programmer knows they're doing that. Not every PL tries to live up to the ideals of Haskell. If you don't want an object mutated in Ruby, you can freeze it.

I don't think they're saying it shouldn't be possible to mutate arguments, just that the ! convention should be enforced. The Ruby runtime could, for instance, automatically freeze all arguments to a function that doesn't end with a !. That way all code that correctly follows the mutation naming convention will continue to work, and any development who doesn't know about it will quickly learn when they try to mutate an argument and get an error. Ideally a helpful error telling them to add the !.

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

#73

Post by stephbook »

Waterluvian wrote: post #51
Aurornis wrote: post #46

Earlier quoted context omitted.

> but I wish I could define in TypeScript “any object passed into this function is now typed _never_. Having explicit language to differentiate between pass by reference and pass by value avoids this confusion. It requires a little more thought from the programmer but it’s really minimal once you internalize it. Rust takes this a step further with an explicit ownership and borrowing model. The compiler will refuse yo…

Yeah exactly. That's what I've loved about Rust and hated about real-world JS. I end up having to reason about an entire case that might not be real at all: does this function mutate what I'm passing it? Should I eagerly deep copy my object? UGH.

Just call "Object.freeze()" before "return" in your function.

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

#74

Post by bnb »

CharlesW wrote: post #38
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.

FWIW, I've been using it server-side via the js-temporal polyfill for some time, no issues.

ooh I'd not seen that yet, will have to take a look.

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

#75

Post by pjmlp »

patchnull wrote: post #6

[flagged]

One of the first things I learnt to appreciate in C++ already during its C++ARM days was the ability to model mutability.

Naturally there are other languages that do it much better.

The problem is that it still isn't widespread enough.

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

#77

Post by WorldMaker »

ravenstine wrote: post #50
patchnull wrote: post #6

[flagged]

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(). In Python terms, it is a bit like formally separating __repl__ and __str__ implementations, respectively. Date's toString() being locale-dependent made it a lot harder to round-trip Date in places like JSON documents if you forgot or missed toISOString().

Temporal's various toLocaleString() functions all take the same Intl.DateTimeFormat constructor parameters, especially its powerful options [1] argument, as Date's own toLocaleString() has had for a long while and has been the preferred approach to locale-aware string formatting.

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

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

#78

Post by bluGill »

WorldMaker wrote: post #71
OptionOfT wrote: post #35

Earlier quoted context omitted.

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

If your friend lives in London it may be useful to have that associated timezone so that you can be sure to message them that day in their timezone. They might better appreciate a message from SF sent on March 10th at 9PM "early that morning in London" than March 11th at 9PM "a day late". A lot of that gets back to why Temporal adds so many different types, because there are different uses for time zone information a…

His birthday is always all day. The question is where he is. If he travels to Japan his birthday won't change - even if he was born late at night and thus it would be a different day if he was born in Japan.

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

#79

Post by causal »

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…

I'm with you on this. I worked on a big Temporal project briefly and I was really turned off by how much of the codebase was just rote mapping properties from one layer to the next.

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

#80

Post by SoftTalker »

NooneAtAll3 wrote: post #68
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

why UTC and not epoch then?

Epoch (a/k/a "unix timestamps") are OK when you just need an incrementing relative time. When you start converting them back and forth to real calendar dates, times, with time zones, DST, leap seconds, etc. the dragons start to emerge.

A lesson I learned pretty early on is always use the date-time datatypes and libraries your language or platform gives you. Think very carefully before you roll your own with integer timestamps.

Post reply on HN