No, I think the canonical format needs to stay wire compatible, but the document could at least say "there's a messy thing here". I think we're stuck with -00:00 and +00:00 being out there; and their meanings not changing. It's more the meaning of 'Z' which seems to more often be aligned with '-00:00' in practice; rather than '+00:00'.
Bron.
On Tue, Dec 17, 2024, at 23:28, Jürgen Schönwälder wrote:
Dear Bron,the problem is that the canonical format uses -00:00 and this is whatcompliant deployed systems are expected to generate. Changing thecanonical format to something different renders deployed systemsnon-compliant. Perhaps this is a reasonable trade-off to make, perhapsit is not. I am not making this call, I believe the WG felt like nottouching this with this update./jsOn Tue, Dec 17, 2024 at 04:09:15AM -0800, Bron Gondwana via Datatracker wrote:> Reviewer: Bron Gondwana> Review result: Ready with Nits>> I am the ARTART reviewer.>> I previously reviewed -16 and had feedback about the datetime formats. Thank> you for taking that feedback on board. I like the text you have for the new> "date" type. I do still think that it would be valuable to include a note> regarding the inadvisability of relying on 'Z' to mean "it definitely happened> in GMT" and recommending always using "+00:00" for that purpose, as well as> advising against producing new data with "-00:00" since it's not defined by the> more recent versions of ISO8601 and this is supposed to be a profile of 8601.>> But I don't think it's worth blocking the document for, hence "Ready with Nits".>> Again, thanks for your great response to my earlier feedback. Otherwise the> document looks great.>>--Jürgen Schönwälder Constructor University Bremen gGmbHPhone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany
--
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
