I agree with Danny. The proper way to handle time zones is at the presentation layer of an application that displays local time for humans. Machines should never use local time for any other purpose.
From: ntp <[email protected]> on behalf of Danny Mayer <[email protected]> Date: Monday, October 31, 2022 at 7:32 PM To: Carsten Bormann <[email protected]> Cc: [email protected] <[email protected]>, [email protected] <[email protected]>, [email protected] <[email protected]>, [email protected] <[email protected]>, [email protected] <[email protected]> Subject: Re: [Ntp] [art] [TICTOC] [Sedate] [Cbor] Two specifications on timestamps nearing WGLC On 10/25/22 4:58 PM, Carsten Bormann wrote: >> I've been reading this thread for a while now. It seems to me that if a >> document from any organization is not publicly available then it shouldn't >> be referenced or used at all in the IETF standards process. > I think this is a position that most of us share. > (There are occasional exceptions; I’m not going to elaborate here, but Max > Weber explained the issue in 1919 using the terms “Gesinnungsethik” and > “Verantwortungsethik”.) > >> If that organization wants the IETF to use it then it needs to make it >> publicly available for free. > That, however, is not very realistic. > We depend on tons of specifications that aren’t available for free. > (For example, NTP/TICTOC make a lot of use of IEEE 1588.) I believe you are talking about the PTP protocol rather than NTP itself. I haven't followed that and I don't know what the rules are for IEEE. However, my observation is that if you want a standard to be a real standard that people will implement then you need to make that standard freely available otherwise they will make up the own version and ignore that standard which has gone through multiple discussions and revisions. > >> It's okay if someone needs to negotiate that but it's a waste of time for >> most people otherwise. > Well, this has to be carefully weighed; there is no one size fits all here. > > In this particular case one of the points of publishing RFC 3339 was to make > a profile of ISO 8601 publicly (and freely) available. However, some salt > was added (the -00:00) that turned out to lead to practical difficulties > interoperating with actual implementations of ISO 8601, and that’s where we > are. > >> I also don't see why the NTP/TICTOC WG is involved in any of this discussion >> as we only deal with UTC and timezones and offsets from timezones is >> irrelevant for the group. > Indeed, the relationship is fleeting, but there was some indication that > NTPv5 will take into account the needs of certain environments where timezone > offsets need to be considered (or are not even known). No, there is no possibility of adding timezone information into NTP. It makes no sense to do so. A client has no idea what timezone it's in and the server doesn't know what timezone a client is in. There's actually no way to do this within NTP. DHCP already has an option to give a system timezone information (I believe it is option 41 but I could be wrong) in RFC8415. Danny _______________________________________________ ntp mailing list [email protected] https://www.ietf.org/mailman/listinfo/ntp
_______________________________________________ TICTOC mailing list [email protected] https://www.ietf.org/mailman/listinfo/tictoc
