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

91–100 of 284 posts

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

#91

Post by WorldMaker »

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?

Right, browsers own it instead of websites needing to rebuild Moment.js bundles. Additionally, most browsers pass the ownership further to the user's OS as the IANA timezone database is a useful system-level service and best updated at the cadence of OS "required" updates.

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

#92

Post by [deleted] »

Xenoamorphous wrote: post #83
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…

> The worst are methods that both mutate and return values Been bitten a few times by Array.sort(). Luckily there’s Array.toSorted() now.

[deleted]

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

#93

Post by themafia »

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 a programmer. I'm a human. Perhaps we should also allow for some "human theory" inside our understanding.

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

#96

Post by xp84 »

idle_zealot wrote: post #72
goatlover wrote: post #42

Earlier quoted context omitted.

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…

That's really interesting. Although my worry is the freezing having bad effects down the line after the function returns.

  a = [1, 2]
  
  def check_this(arr)
    raise "doesn't start with 1" unless a.first == 1
  end

  check_this(a)
  
  a
Now, if you could temporarily freeze, and then unfreeze only the ones you froze, that could be really cool.

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

#98

Post by hrmtst93837 »

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.

[flagged]

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

#99

Post by Maxion »

bluGill wrote: post #78
WorldMaker wrote: post #71

Earlier quoted context omitted.

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.

The other fun ones are daily recurring events for e.g. taking some medication. You take the last one at 10pm before going to bed. You go on a trip which moves you three hours east. Now your calendar helpfully reminds you to take your meds at 1 am.

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

#100

Post by Bratmon »

flyingmeteor wrote: post #52
VanCoding wrote: post #37

Earlier quoted context omitted.

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.

You would need to use the `reviver` parameter of `JSON.parse()` to revive your date strings to Temporal objects. As others have said, it's a simple `Temporal.from()` https://developer.mozilla.org/en-US/docs/Web/JavaScript/Refe...

Having to provide a complete schema of your json everywhere your json gets parsed negates the advantages of json.
Post reply on HN