Draft: draft-ietf-sedate-datetime-extended

Commentary: ( Elective , ignore option if not understood ) ( Critical , must understand / must reject date if not understood ) 
 It 's possible for a timestamp 's offset to conflict with the timezone extension . Usually this is caused by a programmer bug where the wrong offset or the wrong timezone was put in the string . However , in rare cases changes to TZDB rules can cause a conflict . Assume was stored by a program running in 2018 using TZDB rules in effect that time . But after Brazil 's time zone rules were changed in April 2019 , the correct offset for that point in time is now . How should the SEDATE standard deal with conflicts like this ? UPDATE 2022 - 03 - 21 : Our ( Temporal team 's ) understanding is that the WG wants the new standard to be a strict superset of RFC 3339 , which implies that the timestamp should be considered a higher priority than the bracketed time zone extension . Using the Brazil example above , a timezone - aware implementation using the current  should interpret ( now the wrong offset ) as the same timestamp but a different local time : . If this understanding is correct , then here 's strawman text for discussion : Our assumption is that a later standard ( maybe the same one that will standardize floating times ? ) may provide a way to encode a different conflict - resolution preference into timestamp strings . Note that the offset exception is needed because , as noted in , many applications ( and libraries like ) use to mean " I do n't know the local offset " . < details < summaryORIGINAL CONTENT ( LONG)</summaryHere 's how Temporal handles conflicts like this in our current API design : " conflict " means that the date and time shown in the timestamp is not valid for the time zone in brackets , according to the TZDB rules that the parsing program is using . there 's a conflict , by default an exception is thrown when parsing . offset will never cause a conflict , because Temporal interprets as a " null time zone " that is not asserting anything about the local date or local time in a real place on earth . Therefore , the bracketed time zone will take precedence if a offset is used . can optionally override the behaviors above by calling the parsing function using an optional parameter that controls parsing behavior : will make the offset win , will make the bracketed extension win , and is the default behavior . We 'd prefer the standardized behavior to be compatible with the current Temporal implementation described above . But if we must make a change , then we 'd be OK to change the default behavior from " throw an exception in case of conflict " to " non - Z offsets always win " . We think that " throw on conflict " is the best default behavior because it helps the developer detect conflicts which would otherwise go unnoticed by the 99 % of developers who 'll never anticipate possible conflicts . But we also acknowledge valid arguments in favor of an " offset wins by default " behavior . We WOULD NOT be OK with a behavior that always rejects Z offsets with bracketed time zones , because that would prevent creating strings where the original local date / time is unknown . This " do n't know the offset " limitation is very common for timestamps stored in a relational database and other systems that only store a " time since epoch " value without an offset . In those cases , there 's no clear alternative to using a Z offset in the string . We WOULD NOT be OK with a change that prevented Temporal from providing callers with an option ( see ( 4 ) above ) to override the default conflict - resolution behavior . The ability for callers to have an opt - in way to decide conflict resolution behavior is important because , as discussed above in the Brazil example , in rare cases valid strings will later become conflicting . In many cases , it 's not practical for these previously - stored strings to be updated . ( For example , they may be stored in a database owned by someone else . ) So programmers need to have a way to deal with those kinds of strings if they receive them . < /details 
 and I discussed this issue tonight in context of recent discussions on the WG , and I just updated the OP to simplify and and clarify Temporal 's requests to align with the latest WG discussions . Apologies for late - breaking updates , but hopefully it should simplify the discussion in the real - time meeting . 
 ( see also discussion under ) 
 While most of this is covered by the new Section 2 , we could discuss what is remaining under .
However,
all have an internal inconsistency or an unrecognized suffix key/
value, so a recipient MUST treat the Internet Date/Time Format string
as erroneous.
Note that this does not mean that an application is disallowed to
perform additional processing on elective suffix tags, e.g., asking
the user how to resolve the inconsistency.  It means it is not
required to do so with elective suffix tags, but is required to
reject or perform some other error handling when encountering
inconsistent or unrecognized suffix tags marked as critical.