Dear Bron, the problem is that the canonical format uses -00:00 and this is what compliant deployed systems are expected to generate. Changing the canonical format to something different renders deployed systems non-compliant. Perhaps this is a reasonable trade-off to make, perhaps it is not. I am not making this call, I believe the WG felt like not touching this with this update. /js On 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 gGmbH Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany -- last-call mailing list -- last-call@xxxxxxxx To unsubscribe send an email to last-call-leave@xxxxxxxx