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

[Edward Welbourne <[e-mail]>]

On 11/1/22 9:33 AM, Edward Welbourne wrote:
>>> [snip] So they have to store the event's timing relative to a
>>> specified zone.

John C Klensin (4 November 2022 02:57) replied:
> Not enough, even before getting to Paul's corner cases.  Suppose
> it is not, summer in the location where the event will be
> located and the only time zone information is an offset.
[snip]
> If all the information we have available is a time zone
> expressed as a numeric offset, there is not enough information

That's why I said to specify the zone, not its offset at some specific
time.  A zone (usually implicitly) contains information about how its
offset varies with time.  An offset is, indeed, insufficient.  A zone
is, aside from the cases Paul points out, enough.

--On Tuesday, November 1, 2022 11:18 -0400 Paul Kyzivat <[e-mail]> wrote:
>> Interesting corner case. But is solving it worth the hassle?

Yes.  When I'm organizing travel, it's mildly irritating that I can't
set the start and end times of the flight in different zones (the way
the airline tells me them), but I can cope with making the needed
adjustment to one of them so they're expressed in relation to the same
zone.  I get the train time at the other end, on the other hand, from a
rail information system that takes its zone for granted, and I'll be in
that zone by the time I catch the train, so I record it in my calendar
as being specified in that zone.  The calendar duly shows it in the
"block diagram" of the day converted to whatever zone I'm currently in,
so that it's correctly positioned in relation to my flight, but when I
look at the details of the train journey the calendar remembers that
those are *specified* in the destination zone, not my current one.

That's important because, aside from not wanting to do the zone
conversion in my head for every step of the journey at the other end, it
gives me reassurance later that I did in fact remember to use the right
zone for that part of my planning; I'm not going to get a nasty shock on
reaching the station, discovering that I've missed the train by an hour,
or that I have an hour to wait.  And my 'phone auto-switches zone for me
when I switch it back out of airplane mode on landing.

All of which is relevant even if the zone doesn't change its rules
between planning and execution.

>> If so then what about the situation where the politicians
>> redefine how a particular area is divided up into time zones?
>> For example, where it is decided to carve out a new set of
>> time zone rules for a subregion of an existing time zone. Or
>> if a city near a time zone boundary is moved into the
>> neighboring time zone. What would be required for calendars to
>> handle this?
>>
>> These are rare events, rarer than changing the rules for an
>> existing time zone. But neither happens very often for any
>> given place. Where do you draw the line and say "we'll let
>> people deal with this manually".

> Or, as an almost-different question, "where do you draw the line
> and extend the syntax to allow a precise latitude and longitude
> as well as a conventional time zone?".  Presumably, that
> information, or something else that identifies a locale
> geographically rather than politically, would be needed for a
> user (or a rather smart agent acting for a user) to make the
> sorts of adjustments Paul describes above.    And it is easy to
> imagine a user agent/ presentation layer smart enough to accept
> "10AM in Kingston, Jamaica on the fifth of July 2023" and
> putting "2023-07-05 10:00 -0500 18°00'N/76°47'W" or equivalent
> into a calendar database in some appropriate format.

Ideally, in fact, the calendar would record "Kingston, Jamaica" instead
of a latitude and longitude.  There may be some cities which straddle a
zone boundary, in which case it may be necessary to distinguish their
West and East sides.  That records something the user will understand
when it's displayed to them and is what software has some chance of
knowing about.

Of course, usually time-zones are specified by a representative city;
the time-zone database doesn't know about other cities, although
potentially someone could compile a database of such to supplement what
the TZDB knows.  So Paul's corner-case remains a problem there -
thankfully, it is significantly rarer than politicians changing the
rules of the zone you're dealing with.

	Eddy.