The Temporal API Is Awesome(taro.codes)
taro.codes
The Temporal API Is Awesome
https://taro.codes/posts/2023-08-23-temporal-api/
8 コメント
I'm currently procrastinating my task of migrating an entire frontend from MomentJS to date-fns. I hate dates, and I hate this work. I would be overjoyed if we get a standard.
Funnily enough, date-fns-tz is MUCH worse than moment-timezone, so much so that I'm regretting making the decision to migrate. It works by fundamentally altering the Unix timestamp of the underlying date, so that when you format() it, the times appear correct. But try to actually pull a unix seconds out of it and you're screwed.
I should have stuck with the larger bundle size. Aside from Moment being mutable and non-tree-shakeable, the api is better in every way if you care about fixed, non-local timezones.
Funnily enough, date-fns-tz is MUCH worse than moment-timezone, so much so that I'm regretting making the decision to migrate. It works by fundamentally altering the Unix timestamp of the underlying date, so that when you format() it, the times appear correct. But try to actually pull a unix seconds out of it and you're screwed.
I should have stuck with the larger bundle size. Aside from Moment being mutable and non-tree-shakeable, the api is better in every way if you care about fixed, non-local timezones.
This is the fundamental limitation of the current built-in API, and the reason that Temporal is necessary: a Date object has no concept of timezones, and there is no way to inject that into it. It can kind of comprehend that UTC exists, and you can pass dates into the relevant Intl API and get dates formatted in the right timezone, but doing maths on different timezones is nearly impossible to do correctly.
This is the biggest flaw with date-fns - it's great if you're only working with naive timestamps where timezones aren't an issue, but there's fundamentally no way to get things to work correctly when timezones do show up.
This is the biggest flaw with date-fns - it's great if you're only working with naive timestamps where timezones aren't an issue, but there's fundamentally no way to get things to work correctly when timezones do show up.
I think Date is worse that something that has no concept of timezones. It has just enough of a concept of timezones to mess things up, but not enough to implement anything correctly.
Yikes, that doesn't sound like fun. Dates seem inoffensive at first sight but turn out to be really hard to do.
Have you tried Luxon?
If your frontend isn't completely critical, you might be ok with the temporal-api polyfill, too. It's a joy to use.
Have you tried Luxon?
If your frontend isn't completely critical, you might be ok with the temporal-api polyfill, too. It's a joy to use.
Also: This seems like such an obvious quality of life update. Is there a reason Chrome is dragging their feet? What about bun/deno? This could be a huge differentiator for them.
100%. I've tested deno with the feature flag — all it needs is the upstream v8 to unflag it
deno repl --v8-flags=--harmony-temporal
I couldn't test it in bun, but it should be the same thing, except that it depends on JavaScriptCore instead of v8. But basically nodejs, deno and bun don't really need to do anything — just wait for v8 and JSCore.
Browsers are waiting for the proposal to signal that it's ready to be unflagged. Right now it states it must be behind a flag.
deno repl --v8-flags=--harmony-temporal
I couldn't test it in bun, but it should be the same thing, except that it depends on JavaScriptCore instead of v8. But basically nodejs, deno and bun don't really need to do anything — just wait for v8 and JSCore.
Browsers are waiting for the proposal to signal that it's ready to be unflagged. Right now it states it must be behind a flag.
Have you tried Luxon?
It's only the second time I dare share a link to an article I wrote. I find it intimidating, honestly.
I put a ton of effort into writing the article (and creating the no-dependencies runnable-script widget). Would love your feedback / constructive criticism :)