This can’t come quick enough, it’s miles better than the current sorry state of date handling in JavaScript and the proposal (and its polyfill implementations) is event better than userland solutions in terms of correctness, completeness and ease of use.
I’ve integrated Fullcalendar polyfill recently for a project and I love how it’s much harder to shoot yourself in the foot. And the proposal docs are good enough to get started! I’m sure it will improve in the future with more quick recipes.
“Time” is pretty ambiguous. It definitely does cover the broad concept of “time” as in “temporal,” but it can also mean specifically an instantaneous moment. Like, “Throughout time…” vs. “The time is 1330 UTC”. “Temporal” is not ambiguous in this way.
Like, Time.PlainMonthDay scans oddly, since a month-day isn’t a time, it’s a specific day in a month (e.g. “4th of july”. Of course, it does make sense if you come in already knowing that Time is being used as in “temporal,” but if you are relying on that prior knowledge, why not just use Temporal?
(This ambiguity is especially gnarly for non-English speakers, I think.)
I’ve followed this proposal a bit, but I do find myself confusing Temporal with Signals - and was quite surprised to see signals landing. My thinking after reflecting is that I associate signals with values that change over time, and “temporal” gives me connotations of things that exist over time, rather than time values themselves. I like Python’s datetime - simple, obvious, includes both date and time (vs the Date constructor in current JS).
This site fails to render properly on Firefox Mobile, which is equal parts annoying and hilarious, but the spec itself is going to be wonderful to have.
Firefox 134.0.2 on Android on a Pixel 9 Pro. The code blocks are too wide, causing the text to overshoot the right edge and requiring constant side-scrolling. While I can zoom out, that results in the hamburger menu being in the wrong spot (comes inward toward the middle). I can take a screenshot in a bit if there’s a place to file these kind of issues, but I didn’t really think it was worth making a Bugzilla
Similar to another comment on here, we migrated to it (with polyfills) on a large project, and we were happy with the transition. I left the project about 6 months after that, so it’s possible that latent snakes emerged. But while I was there, it resolved many known headaches, and it was not a source of bugs or confusion. I would do it again.
I don’t know the exact history of this feature, but I believe it was largely influenced by Java’s newer time API, which was influenced in turn by Joda Time.
I like how the half minute is there. But why don’t they show the thirty second offset in the TZ part of the representation? It’s weird to just show two-thirds of it.
I’ll summarize my answer here as well. This is because the RFC 9557 string format doesn’t allow HH:MM:SS in the offset part, so we don’t want to output a string that other clients may not be able to parse. Temporal does accept the string 1969-12-31T23:15:30-00:44:30[Africa/Monrovia] and hopefully future improvements to RFC 9557 will allow outputting it as well. The -00:45 string is still correctly “unrounded” to -00:44:30 when appropriate for the given time zone, so it does round-trip correctly.
JavaScript is stuck with the same API for almost 30 years
Given how much the JS language, the JS engines, the overall JS tooling has progressed over the last decade, what do you think took Date so long to get fixed?
My guess is that we’re finally done migrating desktop apps into the cloud and can again focus on making the Web a global platform once again. And what’s more global than the properly localized time?
This can’t come quick enough, it’s miles better than the current sorry state of date handling in JavaScript and the proposal (and its polyfill implementations) is event better than userland solutions in terms of correctness, completeness and ease of use.
I’ve integrated Fullcalendar polyfill recently for a project and I love how it’s much harder to shoot yourself in the foot. And the proposal docs are good enough to get started! I’m sure it will improve in the future with more quick recipes.
It’s great when past problems can be fixed rather than being simply stuck with them forever.
That said, I do hope we don’t run out of synonyms for date/time.
Yeah, why isn’t this just called “Time”? Is that already a thing in JS?
“Time” is pretty ambiguous. It definitely does cover the broad concept of “time” as in “temporal,” but it can also mean specifically an instantaneous moment. Like, “Throughout time…” vs. “The time is 1330 UTC”. “Temporal” is not ambiguous in this way.
Like,
Time.PlainMonthDayscans oddly, since a month-day isn’t a time, it’s a specific day in a month (e.g. “4th of july”. Of course, it does make sense if you come in already knowing thatTimeis being used as in “temporal,” but if you are relying on that prior knowledge, why not just useTemporal?(This ambiguity is especially gnarly for non-English speakers, I think.)
My 2 bits
I’ve followed this proposal a bit, but I do find myself confusing Temporal with Signals - and was quite surprised to see signals landing. My thinking after reflecting is that I associate signals with values that change over time, and “temporal” gives me connotations of things that exist over time, rather than time values themselves. I like Python’s
datetime- simple, obvious, includes both date and time (vs theDateconstructor in current JS).I’ve been using the Polyfill since the early days.
Temporal is the best, most powerful date manipulation API I’ve ever worked with.
I can just wish for every other language to copy it.
This site fails to render properly on Firefox Mobile, which is equal parts annoying and hilarious, but the spec itself is going to be wonderful to have.
even funnier to read, given your handle
Seems fine on Android Firefox and Fennec. Or do you mean the WebKit based iOS version?
Firefox 134.0.2 on Android on a Pixel 9 Pro. The code blocks are too wide, causing the text to overshoot the right edge and requiring constant side-scrolling. While I can zoom out, that results in the hamburger menu being in the wrong spot (comes inward toward the middle). I can take a screenshot in a bit if there’s a place to file these kind of issues, but I didn’t really think it was worth making a Bugzilla
Same on Chrome mobile on Android for me. Page goes outside of borders, zooming out fits the text but then the header is only 3/4s of the screen.
The banner image might be the culprit, making it too wide. I wouldn’t say it’s a rendering issue.
Does anyone know of any flaws or infelicities in this? Temporal like such an improvement that even other language ecosystems have adopted it.
Similar to another comment on here, we migrated to it (with polyfills) on a large project, and we were happy with the transition. I left the project about 6 months after that, so it’s possible that latent snakes emerged. But while I was there, it resolved many known headaches, and it was not a source of bugs or confusion. I would do it again.
I don’t know the exact history of this feature, but I believe it was largely influenced by Java’s newer time API, which was influenced in turn by Joda Time.
So the adaptation most probably comes from Java.
Seems that their support of Local Mean Time is somewhat working:
I like how the half minute is there. But why don’t they show the thirty second offset in the TZ part of the representation? It’s weird to just show two-thirds of it.
Hey, are you the same Janus who posted https://github.com/tc39/proposal-temporal/issues/3079? Thanks for taking the time :-) Funny, I was just about to reply to this post when I saw the GitHub issue come in.
I’ll summarize my answer here as well. This is because the RFC 9557 string format doesn’t allow HH:MM:SS in the offset part, so we don’t want to output a string that other clients may not be able to parse. Temporal does accept the string
1969-12-31T23:15:30-00:44:30[Africa/Monrovia]and hopefully future improvements to RFC 9557 will allow outputting it as well. The -00:45 string is still correctly “unrounded” to -00:44:30 when appropriate for the given time zone, so it does round-trip correctly.RFC 9557 inherits this limitation from RFC 3339 which gets it from ISO 8601.
Yeah, I am the same person. Thanks for the detailed reply.
Given how much the JS language, the JS engines, the overall JS tooling has progressed over the last decade, what do you think took
Dateso long to get fixed?My guess is that we’re finally done migrating desktop apps into the cloud and can again focus on making the Web a global platform once again. And what’s more global than the properly localized time?