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

[John C Klensin <[e-mail]>]

--On Friday, November 4, 2022 09:49 +0000 Edward Welbourne
<[e-mail]> wrote:

> 
> 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.

Actually, well, almost.  Going back to the example I gave,
Jamaica is often identified as "EST".  So, in the winter
(starting Sunday here) is Boston.  But Boston switches to "EDT"
while Jamaica does not.  This is why many calendar systems
identify locations, not by offset or traditional three-letter
zone name but by, e.g., "America/Cayman" (same time zone as
Jamaica in recent memory, but potentially subject to the issues
that you and Paul raised because the political authorities are
different).  This, of course, goes directly to your comment
below about specification by representative city.

> --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.

Exactly.

>>> 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.

I can't speak to "usually" because there have been assertions on
the SEDATE and other lists about, e.g., time zone offsets in
fractions of minutes, something I had not heard about "normal"
populations (as distinct from, e.g., scientists with specific
needs) using before.  Certainly I have seen representative city
names used in the TZDB, calendaring programs, and elsewhere,
but, as you sort of point out, finding a "representative city"
given a city or village name can be a challenge.   As an
example, take two fairly small communities, about a half-hour
drive apart, in Arizona called Tuba City and Gray Mountain.
Both are in MST during the winter months.  Tuba City switches to
daylight time; Gray Mountain does not.  For most people,
especially those who have never heard of either, figuring out a
"representative city" is a challenge.  For Gray Mountain, it
turns out to be Arizona/Phoenix, almost 200 miles away, more or
less to the south.   For Tuba City, I believe it is
America/Denver, closer to 600 miles northeasterly.

I think that puts us largely in agreement, but I think we are
talking about applications that the SEDATE specification is not
adequate to handle, at least without either latitude/longitude
information or a supplemental database that identifies all of
the localities in the world with their mappings to
representative cities over time.  I don't know whether the
SEDATE document (and the proposed IXDTF) requires additional
extensions to allow identifying a precise locality or whether
the definitions of scope and applicability in Section 1 "merely"
need additional explanation, but it does not feel to me as if it
is quite finished yet.

best,
   john