Draft: draft-ietf-sedate-datetime-extended

Commentary: supports offset time zones , e.g. . For backwards compatibility , this RFC should support them too . This PR also adds clarifying text to several time - zone - related definitions . 
 Makes sense . Should I start one ? Yep , we these in Temporal primarily for compatibility with prior art in In  ( and currently in Temporal ) a time zone ID can either be an IANA name or an offset . The ID is an index into a set of rules ( in  , in Temporal ) for converting between exact time and local time . If the ID is an offset , there 's only one trivial rule because the offset is always the same . I do n't have a strong opinion about the name of offset time zones . 
 - Let me know if you have responses to the questions in my comment above , or how you 'd like me to change this PR . Thanks ! 
 I think we still need the mailing list discussion first . If we get to a certain state of clarity by March 18 , we might be able to post yet another update of the draft right before IETF week . 
 Sounds good . I sent mail to the mailing list . Waiting for responses . 
 I plan to merge this within a couple of hours , so we have a merged draft to look at in Monday 's WG meeting . Since the discussion has n't concluded yet , I 'll edit the merge so it is useful for those discussions ; we can edit some more after Monday 's meeting . 
 Sounds good to me . Based on your comments here and on the mailing list , I think we 're in agreement on the important points . 
 Hi - is the merged draft available ? If not , I 'm happy to make the edits you and suggested here in this PR , but did n't want to step on changes you 're making in parallel . Let me know how I can help . Thanks ! 
 I merged the PR and made some edits in main . I included you in the contributor list ; please advise if that is OK , the information is right and whether you want to include any more contact / affiliation information . 
 Great ! Your edits look good to me . I may follow up after the meeting with minor text clarification PRs but nothing important . Info looks right . I 'm a volunteer not working on behalf of my employer so no need for additional affiliation . Thanks ! 
 The current ABNF for the time zone extension does not support offset time zones , e.g. . These zones are supported in , which is the prior art driving the bracketed time zone extension format . Therefore , I 'm assuming that it makes sense for the standard to also allow offsets in brackets too . Current ABNF : Suggested ABNF for , where is imported from RFC 3339 : Example of  usage : 
 Please excuse my ignorance : What is the meaning of ? We 'd need some text explaining the semantics . 
 This format asserts that derived timestamps ( e.g. add one day ) should also use the offset . It 's mostly for backwards compatibility with It 's not recommended for normal use . Heres the explanatory text I in : 
 I assume that conflicts between the timestamp offset and a bracketed offset ( e.g. ) should be handled the same as other conflicts , per discussion in
The extended date/time format is described by the rule "date-time-
ext".  "date-time" is imported from RFC3339, "ALPHA" and "DIGIT" from
RFC5234.
The extended date/time format is described by the rule "date-time-
ext".  "date-time" and "time-numoffset" are imported from RFC3339,
"ALPHA" and "DIGIT" from RFC5234.