Re: [Sedate] [Ntp] [art] [TICTOC] [Cbor] Two specifications on timestamps nearing WGLC

[Edward Welbourne <[e-mail]>]

Doug Arnold (1 November 2022 14:06) wrote:
> 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.

I wish I could agree with you; all times are UTC inside the code, only
at the point of presentation do politicians' decisions mess with how
it's described.

However, when the user is booking an event several months in advance,
they want to say "that day, that time on that day, in the local
time-zone of that place" and, if the politicians change that zone's
offset from UTC, or DST habits, in the mean time, the calendars that
hold records of that event should all preserve the time and date in that
zone, not the UTC time, of the event.  So they have to store the event's
timing relative to a specified zone.  Consequently, therefore, the data
exchange formats by which calendars tell each other (via content
inserted in e-mails, as often as not) those details need to be expressed
in terms that document the zone and how the time is understood in that
zone.  There are lots of other situations where software *must* likewise
handle zoned date-times.

Then there is the fuzzy zone of what counts as displaying it to humans.
When a web-server lots an error, it's going to convert the time into a
human-readable form to include as a timestamp in the log file.  The
human who is going to read it may well find it more intelligible if the
formatting used is their local time, or the standard zone of the
organization whose server it is, even though that has some weird
behaviour at two points in the year, one of which skips an hour, the
other of which repeats it (with a different offset suffix or zone
abbreviation).  Until the human looks at the log file, it's not being
displayed, but still it goes into the log file in human-readable form.

Having said all of which, I do totally agree with Danny - please keep
anything at all to do with time-zones as far away from NTP as possible,

	Eddy.