Tracking issue for syncing with IETF standardization work (req'd before implementers can ship unflagged) #1450
Comments
|
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!)
|
|
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. |
ptomato
added
documentation
|
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. |
The IETF SEDATE Working Group Internet-Draft, "Date and Time on the
Internet: Timestamps with additional information" has reached agreement on
all the open issues. This implements the conclusions of that draft RFC,
which defines a date-time format called Internet Extended Date-Time Format
(abbreviated IXDTF).
IXDTF defines a grammar and semantics for annotations that can be appended
to RFC 3339 strings. We were already using these annotations informally in
Temporal for time zones and calendars. The main things that have to change
are that annotations can have a "critical" flag ("!") which in Temporal
has no effect on time zone and calendar annotations; and that multiple
annotations are possible, where unknown ones are ignored unless they are
marked critical.
See: #1450
This adds a new recognized value "critical" to the calendarName option of the toString() methods of PlainDate, PlainDateTime, PlainYearMonth, PlainMonthDay, and ZonedDateTime. calendarName: "critical" behaves like calendarName: "always", but it also outputs a "!" flag in the calendar annotation. This flag is never used by Temporal, but could be consumed by other programs. See: #1450
…ing() This adds a new recognized value "critical" to the timeZoneName option of ZonedDateTime.prototype.toString(). timeZoneName: "critical" behaves like timeZoneName: "always", but it also outputs a "!" flag in the time zone annotation. This flag is never used by Temporal, but could be consumed by other programs. See: #1450
The IETF SEDATE Working Group Internet-Draft, "Date and Time on the
Internet: Timestamps with additional information" has reached agreement on
all the open issues. This implements the conclusions of that draft RFC,
which defines a date-time format called Internet Extended Date-Time Format
(abbreviated IXDTF).
IXDTF defines a grammar and semantics for annotations that can be appended
to RFC 3339 strings. We were already using these annotations informally in
Temporal for time zones and calendars. The main things that have to change
are that annotations can have a "critical" flag ("!") which in Temporal
has no effect on time zone and calendar annotations; and that multiple
annotations are possible, where unknown ones are ignored unless they are
marked critical.
See: #1450
This adds a new recognized value "critical" to the calendarName option of the toString() methods of PlainDate, PlainDateTime, PlainYearMonth, PlainMonthDay, and ZonedDateTime. calendarName: "critical" behaves like calendarName: "always", but it also outputs a "!" flag in the calendar annotation. This flag is never used by Temporal, but could be consumed by other programs. See: #1450
…ing() This adds a new recognized value "critical" to the timeZoneName option of ZonedDateTime.prototype.toString(). timeZoneName: "critical" behaves like timeZoneName: "always", but it also outputs a "!" flag in the time zone annotation. This flag is never used by Temporal, but could be consumed by other programs. See: #1450
|
It looks like there's been some progress re: the draft? Could we get some news on how this affects progress? |
|
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? |
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 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! |
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. |
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: Awaiting approval any day now... |
|
|
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? |
@jviall See https://tc39.es/process-document/
@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?
|
|
Thanks for the reminder. Will do it next time I make editorial updates. |
|
FYI, the standard is now live as RFC9557 |
|
How soon might we see implementations shipping (without flags)? |
|
@legowerewolf That's up to the implementations now. Some implementations have asked for further changes and I'd expect that they will probably unflag it once those changes have landed in the specification and they've had a chance to catch up their code. Follow #2628 for updates. |
and others
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
The text was updated successfully, but these errors were encountered: