>>> Carsten Bormann <[email protected]> schrieb am 19.10.2022 um 21:44 in Nachricht <[email protected]>: > Hi John, > > thank you for weighing in. > >> (1) The language in RFC 5322 that describes the interpretation >> of -00:00 (actually "-0000" in those specs -- while 8601 makes >> the colon optional, 3339 requires it) and rules about it are >> under review in EMAILCORE. > > Thank you for that pointer! > My summary of the 51(!) messages that mention -0000 (the email date version
> of -00:00) is that implementors don’t really seem to pick up those fine > points, so it is hard to rely on the information that supposedly is being > conveyed. > > Given that the people who do ISO 8601 and RFC 3339 implementations might be > more focussed on time, we might be a bit more optimistic for SEDATE. > >> If people have opinions about that, >> please review those discussions and please, please, do not do >> anything in SEDATE that would produce the possibility of a >> conflicting definition between the two IETF specs. > > I’m not sure what a conflict would be: > — ISO 8601 definitely does not have -00:00 so there will be a difference. > — There is no point in trying to change ISO 8601. > — Some change to RFC 3339 will be needed if there is interest in being able > to express no information about time zone offsets. > — Email headers are not going to change, so they have -0000 but not Z (so > that’s a perfect match to what SEDATE proposes). > > So there always will be a need to translate the time zone offset information > at the same time while translating all the other differences between RFC 3339 > and RFC 2822/5322. > No conflict/incompatibility in sight. The discussion is going away from NTP a bit, but for E-Mail I suppose the original intent of providing a timezone offset is to help computers to get the sorting right, while humans may prefer to see local time stamps. In that perspective using +0000 and -0000 really does not make a difference as the timestamp is in UTC (for humans and computers). Local humans may be able to derive the local time from that, however. [...] Regards, Ulrich Windl _______________________________________________ TICTOC mailing list [email protected] https://www.ietf.org/mailman/listinfo/tictoc
