[tz] Correcting daylight-savings time for central Missouri prior to 1967

Guy Harris guy at alum.mit.edu
Sat Nov 24 19:51:40 UTC 2018


On Nov 24, 2018, at 11:27 AM, Brian Inglis <Brian.Inglis at SystematicSw.ab.ca> wrote:

> On 2018-11-23 16:21, Guy Harris wrote:
>> On Nov 23, 2018, at 3:05 PM, Steve Allen <sla at ucolick.org> wrote:
>>> On Fri 2018-11-23T15:00:31-0800 Guy Harris hath writ:
>>>> So there is no requirement that a tzdb region be a connected space?
>>> I think not.
>> Hopefully the makers of shape files for tzdb regions have taken that into account.
> 
> Check Arizona (AZ), USA - which does not observe DST - Navajo Nation in NE AZ
> observes DST as it also spans NW New Mexico, SE Utah, SW Colorado and those
> states observe DST - the Hopi Reservation enclave and its smaller exclaves
> within Navajo Nation do not observe DST.
> If these areas are appropriately flagged or displayed, the data should be good.

So those would be the America/Phoenix tzdb region, which should include the non-Navajo Nation parts of Arizona, including the Hopi Reservation, and the America/Denver tzdb region, which should include the Navajo Nation.

That means that the America/Phoenix region is not a connected space.

This image:

	https://raw.githubusercontent.com/evansiroky/timezone-boundary-builder/master/2018g.png

doesn't appear to reflect that; hopefully the timezone boundary builder:

	https://github.com/evansiroky/timezone-boundary-builder

supports regions built by adding arbitrary connected spaces to, and removing arbitrary connected spaces from, an initial connected space.

I'll let Deborah Goldsmith address whether Apple's regions (used for the macOS/iOS/etc. location-to-tzdb-region mapping) can, and do, handle this.


More information about the tz mailing list