Sorry, missed this. > On 2022-10-07, at 07:15, Michael Richardson <[email protected]> wrote: > > > Carsten, is there a typo? > > Former: "Section 4.3 of [RFC3339] states that an offset given as Z or +00:00 > implies that "UTC is the preferred reference point for the specified time". > > Latter: "The offset -00:00 is provided as a way to express that "the time in > UTC is known, but the offset to local time is unknown".
That’s not what I called former/latter. >> This convention mirrors a similar convention for date/time information in >> email headers, described in Section 3.3 of [RFC5322] and introduced earlier >> in Section 3.3 of [RFC2822]. > >> The latter convention is in actual use, while >> the former always was handicapped by the fact that [ISO8601:1988] does not >> actually allow -00:00. > > It seems that the -00:00 notation is the "latter", instead it ? The “latter” is what I should have called “RFC 2822/5322 email header date convention”, and the former is the ISO 8601 extension that is in RFC 3339. > I've seen +00:00 and -00:00 regularly in email. > (Actually, I didn't know what -00:00 meant until I read this. It seems > pretty common when email originates through Outlook.com) OK, I casually looked at this in a corpus of email headers I happened to have lying around and only occasionally found -00:00, but it indeed is in actual use. This is data for the email header date format, which is unrelated to ISO 8601 and therefore does not suffer from compatibility issues with ISO 8601. Whoever invented the adaptation of -00:00 to the RFC 3339 format did not have a copy of ISO 8601, did not bother to look, or didn’t think that the resulting incompatibility would be a problem in practice. Turns out, it actually is. Grüße, Carsten _______________________________________________ TICTOC mailing list [email protected] https://www.ietf.org/mailman/listinfo/tictoc
