Tracking issue for syncing with IETF standardization work (req'd before implementers can ship unflagged)
justingrant opened this issue · 45 comments
Although Temporal is currently Stage 3 in order to gather feedback from implementers, implementers must ship Temporal support behind a feature flag until we finish work with IETF to standardize the string formats used for calendar and time zone annotations (e.g. 2020-01-01T00:00[Asia/Tokyo][u-ca=japanese]).
This is a tracking issue so implementers and other interested folks can track the progress of this IETF standardization work.
The current IETF spec is here: https://ryzokuken.dev/draft-ryzokuken-datetime-extended/documents/rfc-3339.html
Hey @ryzokuken are there any updates on when you expect this to be finalized? I am asking in order to know when to expect temporal to be unflagged.
I want to make it clear I am asking because of curiosity and there is no urgency on my side only anticipation :)
@benjamingr thanks for your interest! My priority has been to ship it ASAP but there had been a few roadblocks not too long ago. The new IETF WG (dubbed SEDATE) has been successfully chartered and hopefully the document would be adopted at the next IETF meeting (this month). I think then it would be safe to ship Temporal without this restriction but of course it might take longer to actually implement the entire proposal.
See https://www.youtube.com/watch?v=p-lpfVRxprc
(At the time of this video 2021-07-27) "There are a couple of significant open questions that need to be addressed before submission for publication and they are looking for a volunteer second editor to help with drafting, preferably someone with experience with such proposals"
@somombo not all the open questions block adoption, and a couple of them could be reasonably worked on after the draft is adopted by SEDATE.
Hey @ryzokuken... Same question as @benjamingr (and same qualifier too! Truly appreciate the work you're doing!)
Hey @ryzokuken are there any updates on when you expect this to be finalized? I am asking in order to know when to expect temporal to be unflagged.
I want to make it clear I am asking because of curiosity and there is no urgency on my side only anticipation :)
Hi @MaximSagan, sorry for the delay. The IETF work for the draft has been moving along nicely and there is a proposed interim meeting next week where we plan to finalize thing and aim for publication either in Dec or in Q1 2022 by the latest. In the meantime, this work is being done in the SEDATE WG (http://datatracker.ietf.org/wg/sedate) and you could subscribe to the mailing list on that page to follow any updates.
How's progress? Been dealing with some stuff at work that Temporal would've been really nice for.
It's moving along, albeit slower than I'd expected. It's almost there, but missing some final agreements.
It looks like there's been some progress re: the draft? Could we get some news on how this affects progress?
@legowerewolf that's true indeed. The draft is basically done except one open PR according to my understanding, and should be published as an RFC soon.
@legowerewolf and others: one thing to note is that once we're done, this will be in the ballcourt of the ISO and IETF liasons, who might take their time to review and approve the draft, but it's nearly impossible to predict exactly how long that process might or might not take.
Ha. Of course. Let us know if there's a place to put comments when it's in their hands? Attention may compel speedier action.
Hi all !! I really appreciate all the work you are doing on this. This is gonna solve a ton of problems for everyone.
I understand there are higher powers that need to bless this, but was curious about what the rollout will look like?
Will it start as an official polyfill or are there plans in place for browsers and JS engines to implement this immediately?
I have read the warnings on using this in production, is that still a big warning or are there any polyfills that "should" be safe to start using this in a production environment? Thanks for this, cant wait!!
Hi all !! I really appreciate all the work you are doing on this. This is gonna solve a ton of problems for everyone. I understand there are higher powers that need to bless this, but was curious about what the rollout will look like? Will it start as an official polyfill or are there plans in place for browsers and JS engines to implement this immediately? I have read the warnings on using this in production, is that still a big warning or are there any polyfills that "should" be safe to start using this in a production environment? Thanks for this, cant wait!!
The warnings are there since until IETF gives its blessing, there could be changes requested to the calendar format. In order to not fracture the ecosystem (chrome uses v1 of the format and firefox v2 etc.) use in production is not recommended for now - but as long as you don't rely on the calendar format too much and don't mind a bit of refactoring later you could slowly introduce it through one of the polyfills as an experiment. You have been warned though! 😉
Once the format is standardised it will go to tc39 for stage 4 advancement (if that is given - and there are no signs this won't be the case) it becomes part of the standard and it should be available in browsers fairly quickly (maybe with a wide enough support by the end of 2023/24 is my guess). An official polyfill should also be available by then too in case you target older browsers.
The IETF spec you mention expired on 18 February 2022. What does that mean for this proposal timeline?
The IETF spec you mention expired on 18 February 2022. What does that mean for this proposal timeline?
You can always find the latest version here https://datatracker.ietf.org/doc/draft-ietf-sedate-datetime-extended/
If you click on a version on the timeline you can then click on formats -> html to view it. The latest version 6 can be found at https://www.ietf.org/archive/id/draft-ietf-sedate-datetime-extended-06.html and expires in March next year.
You can read more about how expiry works here https://www.ietf.org/ietf-ftp/ietf/1id-guidelines.html#expiry.
I don't think you need to worry about the draft itself expiring in this case though 👍 Hope that helps
PS: Btw. I don't know if this will be added to the next IETF session but if so session 115 is in November
FYI, the editor's copy is currently at version 6, published a few days ago; I believe it still needs to be submitted to IETF datatracker.
PS: Btw. I don't know if this will be added to the next IETF session but if so session 115 is in November
My understanding is that version 6 is complete and reflects all the changes from the July IETF session. So, only the administrative blockers remain, and it doesn't need to wait for the next IETF session in November.
Shot in the dark here, but wanted to check just in case. I'm giving a talk at UtahJS conference this Friday (Sept 23rd 2022) and as part of it I am covering Temporal. If there happens to be any hot off the presses news on this last remaining blocker by then, It would be super cool if I could drop that in my talk and blow some minds.
Either way, I think I can speak for a large section of JS developers and say that we are all super stoked about all the work being done here and look forward to being able to use the fruits of it. 👏👏👏👏👏
At this point there are no obstacles with the current state of the IETF draft. It's completely in line with what we're doing in Temporal. Anything can happen of course in standards bodies, but there are zero remaining major open issues WRT to the IETF standardization on either the Temporal or IETF side. That doesn't mean Temporal is ready for Stage 4 yet. We still need the IETF draft to be officially adopted, and 2 JS engines need to ship a Temporal implementation. This will take time.
My understanding of where we currently are in the process is that the draft has passed working-group last call and is now awaiting IESG (Internet Engineering Steering Group) review.
Any news yet? Wondering when this could ship unflagged, temporal is a really nice thing to have in JS
first of all awesome works guys, I'm glad that JavaScript is keep improving with the help of people like you. is there any updates on this? i have a good use case for an old project rewrite.
There have been some changes made to the IETF document as a result of the review that I mentioned earlier and it's now awaiting another round of review — you can follow this on https://datatracker.ietf.org/doc/draft-ietf-sedate-datetime-extended/
For those of us who don't follow these processes regularly, can you elucidate where this is at a little?
@limeandcoconut while I've continued making progress on this within IETF, there's a few process roadblocks that are keeping us from publishing the draft (https://datatracker.ietf.org/doc/draft-ietf-sedate-datetime-extended/). While you could continue checking the IETF datatracker and mailing lists for more information, be assured that we're trying everything in our power to standardize the format as soon as we can.
Is there any specific reason that nothing has happened in the last while? It seems like all the issues where fixed and a new draft was proposed, but nobody has responded in August (and the mailing list is also pretty quiet compared to July), is there any kind of ETA when there will be a new decision on the new draft?
Is there any specific reason that nothing has happened in the last while?
The specific reason is a bottleneck in the ART area of the IETF, where we had to make do with one Area Director (AD) since April until a couple of days ago. I expect that bottleneck to go away now, but like with any queue, not instantly.
The specification is in state "Waiting for AD Go-Ahead::AD Followup", so unless the AD finds another hair in the soup the next step is the IESG ballot and then an IESG telechat date. This could be four weeks from now, Sep 21.
👋 Admittedly a naive comment from the peanut gallery, but I've been waiting to use "boring" things in temporal like PlainDate for awhile now.
Granted, I really don't know, but does all of temporal have to blocked on this issue? Or could like 80% of temporal be shipped (...or maybe even the polyfill blessed for production usage? please? :-D) while the 20% of temporal that is really dependent on this IETF blessing is held back?
Thank you! We're really looking forward to this!
@stephenh I totally understand, and I'd admit that I've been waiting for Temporal across environments myself for various side projects. That said, shipping features to the web without doing our due diligence is very risky and therefore we've held off on asking engines to ship before the draft gets published by IETF.
Moreover, it's hard if not impossible to partially ship Temporal since everything's so tightly connected and the draft specifies the interchange format which affects serialization and deserialization of most Temporal types. That said, we are aware that the chance of semantic changes within the format is vanishingly small and if it takes a long time to get it published, we might have to go ahead with Temporal without the IETF's approval.
@ryzokuken gotcha, makes sense! Thank you!
Granted, I really don't know, but does all of temporal have to blocked on this issue? Or could like 80% of temporal be shipped (...or maybe even the polyfill blessed for production usage? please? :-D) while the 20% of temporal that is really dependent on this IETF blessing is held back?
About this specifically! The polyfill in this repo is exclusively for running the tests and the browser playground. There isn't going to be one under the ECMA banner that we claim is production-quality. But there are other efforts underway: https://github.com/tc39/proposal-temporal#polyfills As always, we cannot give any guarantees that the feature will be stable until the proposal reaches stage 4.
Splitting up the proposal to go ahead with the parts that don't depend on the string format; I have been thinking about this as well. I suspect it would require a considerable communications effort in the committee, which would take away from the other things we have to do to keep the proposal moving towards the next stage. You could say that our process should be able to deal with that more easily, and you might be right, but this is the situation.
@cabo it's september 24th and the specification is still in the state of "Waiting for AD Go-Ahead::AD Followup". what does it mean for this proposal?
Hi! The document is waiting on me (I am the Area Director responsible for it and back from leave but still only working part time) - apologies for the delay. I am catching up with the Last-Call discussion ( and hope to send this forward asap. Thank you for your patience!
Quick update: The document is now on the agenda of the next IESG meting (called "telechat" in IETF vernacular), which is on 2023-10-19.
Best case: the document is approved right there.
Likely case: another nit is found to be fixed, we fix it (quickly), and then the document is approved a few days later.
Less likely case: the ceiling caves in, or similar.
Note that we'll get an RFC number approximately two months after approval (RFC editing), but I think it is the approval that is needed here. If you actually need the RFC number, expedited processing is available -- it probably would be good to know that on 2023-10-19.
If you actually need the RFC number, expedited processing is available -- it probably would be good to know that on 2023-10-19.
I didn't hear anything about this — so can I assume the approved document is what you need to proceed, and you'll be happy with the RFC published around the end of the year?
I didn't hear anything about this — so can I assume the approved document is what you need to proceed, and you'll be happy with the RFC published around the end of the year?
We did discuss it. All other things being equal, faster is better if it doesn't require any intervention on our part. But the approved document is likely enough of a signal to unblock implementations.
Eagerly awaiting word about how things went!
I just submitted -11, which is intended to address the IESG comments.
The diffs are generally editorial, please see:
https://author-tools.ietf.org/iddiff?url2=draft-ietf-sedate-datetime-extended-11
Awaiting approval any day now...
IESG state changed:
New State: Approved-announcement to be sent
(The previous state was IESG Evaluation::AD Followup)
The document is approved: https://mailarchive.ietf.org/arch/msg/ietf-announce/g_JdmxVWPKhV_GYYcSKVUk5czjE/ :)
What remains in between document approval and achieving Stage 4?
now that the document has been approved, is this issue ready to close? can implementers ship unflagged now?
What remains in between document approval and achieving Stage 4?
@jviall See https://tc39.es/process-document/
now that the document has been approved, is this issue ready to close? can implementers ship unflagged now?
@SuperchupuDev Yes, in theory they can. In practice, there are not yet any implementations that pass all the tests, so they will probably work on that first. In the next TC39 meeting we'll announce that the IETF process is finished, and hopefully at the same time announce that we have completed test coverage for all of the normative changes up until now. (Some of those are still pending reviews. Follow #2628 for the progress on that.)
I agree, the issue can be closed.
Given this is resolved, should this notice be removed from the README?
NOTE: Although this proposal's API is not expected to change, implementers of this proposal MUST NOT ship unflagged Temporal implementations until IETF standardizes timezone/calendar string serialization formats. See #1450 for updates.
Thanks for the reminder. Will do it next time I make editorial updates.