On Mon, Oct 21, 2024, at 21:38, Jürgen Schönwälder wrote:
Thanks for your review, Bron. See my response inline...On Sun, Sep 29, 2024 at 09:27:56AM -0700, Bron Gondwana via Datatracker wrote:> *Date-Time:*>> While the date-time format duplicates the description found in RFC 6021 and> later RFC 6991, the construct -00:00 has been identified as being incompatible> with the latest ISO8601 by the work in the SEDATE working group. I would refer> you to section 2 of RFC 9557 for the full description and update of RFC 3339> which was done there. I suggest that this document should be updated to align> with (and reference) RFC 9557 and deprecate the usage of -00:00; instead using> "Z" to mean "local time reference point is unknown" as is common practice.> This will improve future interoperability with ISO8601.>> Likewise the same issue occurs with the new "date" format and "time" format.This has been discussed in the WG and the conclusion was to not changethe 'date-and-time' format as it is widely implemented. Note that RFC6020 picked -00:00 as the canonical representation for values in UTCwith an unknown local time-offset. RFC 9557 now suggests to use Zinstead. If we change date-and-time to use Z instead of -00:00, thenexisting implementations of 'date-and-time' become non-compliant.Hence, we prefer to stick to what we have.For the new 'date' and 'time' definitions we can adopt RFC 9557 anduse Z instead of -00:00. This of course means that UTC values with anunknown local time-offset will be reported differently in 'date-andtime' values and 'date' or 'time' values. Yes, all this is somewhatunfortunate. I will update the definitions of 'date' and 'time' tofollow RFC 9557 but I will not touch 'date-and-time' for now unlesslets say the IESG decides that alignment with RFC 9557 is moreimportant than our concerns about compliance of existingimplementations generating canonical representations.
Thanks for your responses - sorry I didn't get back to this until nearly at the end of this IETF meeting!
The decision on whether it's more important to try to align everything we can to the more sensible handling of 'Z' and -00:00, or leave things how they are, is beyond my pay grade! I'll leave it for the IESG to weight the pros and cons.
I do note that the discussion in SEDATE suggested that most everyone is already using Z to mean "it's in UTC but no assertion of physical location" while "+00:00" meant "it happened in this physical part of the earth".
Cheers,
Bron.
--
Bron Gondwana, CEO, Fastmail Pty Ltd
brong@xxxxxxxxxxxxxxxx
-- last-call mailing list -- last-call@xxxxxxxx To unsubscribe send an email to last-call-leave@xxxxxxxx
