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
Same here, this is the way
Temporal: The 9-year journey to fix time in JavaScript
61–70 of 284 posts
Re: Temporal: The 9-year journey to fix time in JavaScript
#62> "It was a straight port by Ken Smith (the only code in "Mocha" I didn't write) of Java's Date code from Java to C."
This is funny to me; Java's util.Date was almost certainly a port of C's time.h API!
Re: Temporal: The 9-year journey to fix time in JavaScript
#63so Temporal is copying cpp's std::chrono?
Re: Temporal: The 9-year journey to fix time in JavaScript
#64Earlier 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...
I've been doing this for so long and never knew there was a reviver param, thanks - that is super useful.
Re: Temporal: The 9-year journey to fix time in JavaScript
#65Earlier 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
I think it's the other way around - he's projecting rust as what he wants
Re: Temporal: The 9-year journey to fix time in JavaScript
#66so Temporal is copying cpp's std::chrono?
More like a copy of Java’s JSR310, which in turn took many years to get right.
Re: Temporal: The 9-year journey to fix time in JavaScript
#67A 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…
It should still be possible to continue using date-fns (or a similar lib) to suit your preference, right?
yes, sure. probably there will even pop up a functional wrapper around the temporal API occasionally. But would've been nice if it was like this from the start.
Re: Temporal: The 9-year journey to fix time in JavaScript
#68My 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?
Re: Temporal: The 9-year journey to fix time in JavaScript
#69Earlier quoted context omitted.
This is possible with the asserts x is y pattern no? https://www.typescriptlang.org/play/?#code/C4TwDgpgBAYg9nKBe...
I think the sticking points are: 1. You cannot return anything (say an immutable result that has consumed the input) Okay, so don't return anything, just mutate the original. Except: 2. You cannot mutate the original, return nothing, but the mutated original isn't a subset of the original. For example: https://www.typescriptlang.org/play/?#code/GYVwdgxgLglg9mABB...
Hmm, I see, yes it's quite limited.
Re: Temporal: The 9-year journey to fix time in JavaScript
#70My 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.