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

On Friday, November 4, 2022 09:49 +0000 Edward Welbourne <[e-mail]> wrote:
>> 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.

John C Klensin (4 November 2022 15:02) replied
> Actually, well, almost.  Going back to the example I gave, Jamaica is
> often identified as "EST".

Time-zone abbreviations do not (unambiguously) identify time-zones.
They are subject to localization and, even in a single language, there
are zones whose abbreviations coincide.  As I said, you need to specify
the zone; hinting at it - whether by an abbreviation or an offset -
fails to *specify* it.

The other problem with abbreviations is that the standard-time version
of an abbreviation is commonly used also to denote the zone when
understood regardless of time of year; so "Norway uses CET" implicitly
says that it also uses CEST in summer (for now - I hear rumours of a
plan to scrap DST in the EU, but see no action towards it).

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

The Netherlands, until 1937, was the last to stop doing that.  They had
their own Royal Observatory, IIRC, which defined time just as Greenwich
did; that put it 19 minutes 32.13 seconds ahead of GMT.  On 1937-07-01
they rounded that to 20 minutes; except that they were in summer time at
the time, so that was 1h 20m for the rest of the summer.

Zones in the TZDB include an "LMT" period (local (solar) mean time)
before the relevant jurisdiction switched to using a common time zone.
TZDB only gives these to the nearest second (and enough of them are
given as round numbers of minutes that I suspect at least some are
rounded to the nearest minute), probably because most of them weren't
precisely defined.

A second's difference in offset corresponds to 15 arc seconds of
longitude change, which is a bit under half a kilometre at the equator
and less - in proportion to cos(longitude) - away from it.  So a typical
city is wider than a second in its local solar mean time variation,
making finer-than-second precision only meaningful where there was a
specific location used to define it and an observatory located there to
measure it to that precision.

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

Indeed - but you can always ask the person you're booking a meeting with
what city their 'phone uses to identify their present zone.  As long as
the zone doesn't shift its boundaries between then and the event, you
should be fine.

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

Fun ;^>
Take a look at Indiana's zone history some time.
https://github.com/eggert/tz/blob/main/northamerica#L858
(through line 1098).

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

hmmm ... probably better, for each city in the TZDB, to have some
description of the boundary of the region it represents, in each of of a
succession of time periods bounded by the changes.  I guess a polygon
expressed relative to OpenStreetMap's open-source data would make a good
way to do that.  Might need to be several polygons in some cases, or a
polygon with a hole.  But still more manageable than trying to list
every place-name within such a polygon.

	Eddy.