On 2016-05-24 16:55, Arthur David Olson wrote:

On Tue, May 24, 2016 at 6:43 PM, Deborah Goldsmith <goldsmit@apple.com <mailto:goldsmit@apple.com>> wrote:

...

A colleague recently visited Page, Arizona, and the Navajo reservation right next to it. His phone must have been associated with a cell tower inside the Navajo nation, because his zone was set by NITZ to America/Denver (DST in effect). This matches the current TZ database. However, he observed that the parts of the Navajo nation adjacent to Page were actually observing the same time zone as Page (America/Phoenix, DST not in effect). I wouldn’t make any changes based on this one anecdote, but it might be worth checking if anyone has any sources inside the Navajo nation. The source used back in 1987 (using--ahem--snail mail) was the Inter Tribal Council of Arizona: http://itcaonline.com/.

Nothing has changed in AZ, which has a daylight saving donut: http://www.lapahie.com/Pictures/Navajo_Map_Lg.jpg http://www.azcentral.com/story/news/local/arizona/2016/03/12/arizona-dayligh... http://www.cntraveler.com/stories/2012-11-12/daylight-saving-donut-arizona-k... TL;DR: The Navajo nation includes areas in UT, CO, NM, which observe DST, so the parts in AZ also observe DST. Federal facilities and areas within AZ are subject to federal legislation so they too observe DST. The Hopi nation, encircled by the Navajo nation, but wholly within AZ, stays on MST. Page, while within the boundaries of the Navajo nation, was swapped for state land, so stays on MST. The time observed in any location will depend on the applicable legislation, and/or its main commercial links. The time you get from any cell tower may depend on its location and/or what the company considers its main service area. How do OS X and iOS deal with local time in AZ/Navajo/Hopi/Page, and federal parks and facilities in AZ? -- Take care. Thanks, Brian Inglis, Calgary, Alberta, Canada

On May 24, 2016, at 10:11 PM, Deborah Goldsmith <goldsmit@apple.com> wrote:

...

How do OS X and iOS deal with local time in AZ/Navajo/Hopi/Page, and federal parks and facilities in AZ?

I gave the one data point I have. :-)

Which was

...

His phone must have been associated with a cell tower inside the Navajo nation, because his zone was set by NITZ to America/Denver (DST in effect).

OK, so I've read 3GPP TS 22.042 version 13.0.0 Release 13, and it says: The serving PLMN shall make Local Time Zone (LTZ) available to the MS as an offset from Universal Time in units of 15 minutes. When the LTZ is compensated for DST (summertime), the serving PLMN shall provide a DST parameter to indicate this. The adjustment for DST can be +1h or +2h. which looks like it corresponds only to the information in one of the entries for an IANA tzdb zone (but without the time zone abbreviation), not to all of the entire tzdb zone's (i.e., it's useless for converting any times before or after any transition times). So: 1) Is it known that it was set by NITZ, or is it just assumed that it was set by NITZ rather than "take the location given by Location Services, look it up in the shape maps, and convert that to a tzdb tzid"? 2) If so, how does one determine a tzdb tzid, such as American/Denver, from the offset from UTC in units of 15 minutes and "a DST parameter" in whatever form it takes (presumably some *other* 3GPP spec says how that stuff goes over the air, because TS 22.042 v13.0.0 sure doesn't), as would be required by the zone "[being] set by NITZ to American/Denver"? If the system time zone *wasn't* set by NITZ, then, in answer to Brian Inglis's question: 1) it's presumably handled by code that uses tzdb files (definitely for UN*X APIs, although I think some frameworks have their own code to read the tzdb files - I seem to remember that the two separate projects containing the two bits of code had their own copies of the tzdb source files and compiled them independently, but that the tzdb files were later put into a separate "tz data" project, so the two bits of code would at least share the underlying data); 2) OS X 10.11.5's tzdb files look as if they have the usual America/xxx zones; 3) as far as I know, somewhere in the bowels of OS X and iOS there's code that can get information from Core Location: https://developer.apple.com/library/ios/documentation/CoreLocation/Reference... https://developer.apple.com/library/mac/documentation/CoreLocation/Reference... look it up in what I presume are maps of the tzdb zone boundaries, and determine the appropriate tzdb tzid, which is the behavior if you tell the machine to automatically pick the zone - you can also manually configure it. So, by "However, he observed that the parts of the Navajo nation adjacent to Page were actually observing the same time zone as Page (America/Phoenix, DST not in effect).", do you mean "if he went to parts of the Navajo nation adjacent to Page, his phone reported DST not being in effect" or "if he went to parts of the Navajo nation adjacent to Page, the clocks he saw reported DST not being in effect"?

So, by "However, he observed that the parts of the Navajo nation adjacent to Page were actually observing the same time zone as Page (America/Phoenix, DST not in effect).", do you mean "if he went to parts of the Navajo nation adjacent to Page, his phone reported DST not being in effect" or "if he went to parts of the Navajo nation adjacent to Page, the clocks he saw reported DST not being in effect"?

The latter: residents of the Navajo nation (adjacent to Page, at least) were not using DST; they were using the same time as Page. My colleague did not directly observe their clocks, just what the residents said their clocks were. The whole issue came up because he had an appointment inside the Navajo nation, and the time on his phone (observing DST) was off from the time the people he was meeting by an hour, because they were not observing DST. Debbie

On May 26, 2016, at 1:17 AM, Guy Harris <guy@alum.mit.edu> wrote:

...

On May 24, 2016, at 10:11 PM, Deborah Goldsmith <goldsmit@apple.com> wrote:

...

How do OS X and iOS deal with local time in AZ/Navajo/Hopi/Page, and federal parks and facilities in AZ?

I gave the one data point I have. :-)

Which was

...

...

His phone must have been associated with a cell tower inside the Navajo nation, because his zone was set by NITZ to America/Denver (DST in effect).

OK, so I've read 3GPP TS 22.042 version 13.0.0 Release 13, and it says:

The serving PLMN shall make Local Time Zone (LTZ) available to the MS as an offset from Universal Time in units of 15 minutes.

When the LTZ is compensated for DST (summertime), the serving PLMN shall provide a DST parameter to indicate this. The adjustment for DST can be +1h or +2h.

which looks like it corresponds only to the information in one of the entries for an IANA tzdb zone (but without the time zone abbreviation), not to all of the entire tzdb zone's (i.e., it's useless for converting any times before or after any transition times).

So:

1) Is it known that it was set by NITZ, or is it just assumed that it was set by NITZ rather than "take the location given by Location Services, look it up in the shape maps, and convert that to a tzdb tzid"?

2) If so, how does one determine a tzdb tzid, such as American/Denver, from the offset from UTC in units of 15 minutes and "a DST parameter" in whatever form it takes (presumably some *other* 3GPP spec says how that stuff goes over the air, because TS 22.042 v13.0.0 sure doesn't), as would be required by the zone "[being] set by NITZ to American/Denver"?

If the system time zone *wasn't* set by NITZ, then, in answer to Brian Inglis's question:

1) it's presumably handled by code that uses tzdb files (definitely for UN*X APIs, although I think some frameworks have their own code to read the tzdb files - I seem to remember that the two separate projects containing the two bits of code had their own copies of the tzdb source files and compiled them independently, but that the tzdb files were later put into a separate "tz data" project, so the two bits of code would at least share the underlying data);

2) OS X 10.11.5's tzdb files look as if they have the usual America/xxx zones;

3) as far as I know, somewhere in the bowels of OS X and iOS there's code that can get information from Core Location:

https://developer.apple.com/library/ios/documentation/CoreLocation/Reference...

https://developer.apple.com/library/mac/documentation/CoreLocation/Reference...

look it up in what I presume are maps of the tzdb zone boundaries, and determine the appropriate tzdb tzid, which is the behavior if you tell the machine to automatically pick the zone - you can also manually configure it.

So, by "However, he observed that the parts of the Navajo nation adjacent to Page were actually observing the same time zone as Page (America/Phoenix, DST not in effect).", do you mean "if he went to parts of the Navajo nation adjacent to Page, his phone reported DST not being in effect" or "if he went to parts of the Navajo nation adjacent to Page, the clocks he saw reported DST not being in effect"?

On May 26, 2016, at 3:38 PM, Guy Harris <guy@alum.mit.edu> wrote:

On May 26, 2016, at 6:36 AM, Deborah Goldsmith <goldsmit@apple.com> wrote:

...

...

So, by "However, he observed that the parts of the Navajo nation adjacent to Page were actually observing the same time zone as Page (America/Phoenix, DST not in effect).", do you mean "if he went to parts of the Navajo nation adjacent to Page, his phone reported DST not being in effect" or "if he went to parts of the Navajo nation adjacent to Page, the clocks he saw reported DST not being in effect"?

The latter: residents of the Navajo nation (adjacent to Page, at least) were not using DST; they were using the same time as Page. My colleague did not directly observe their clocks, just what the residents said their clocks were.

So they might just be ignoring the Navajo nation's rules and using their neighbor's rules instead; I think that's done elsewhere as well, near time zone boundaries (I think there may be cases where a location that's far from other places in its own time zone, but close to a location in another time zone, sets its clocks as if they were in the other time zone).

It may also be a technology issue. Clearly modern smartphones can use shapefile data and their onboard GPS to derive timezone offset from the location, and possibly some do. But I gather from earlier messages today that cell base stations also send their offset. Obviously, a phone that relies on the base station to supply offset will have the wrong answer if it is in a different zone than the base it happens to be listening to right now. It would not be a surprise if the "near Page" example is caused by this cell tower issue. All these anecdotes suggest the need to verify that the rules as we believe them to be defined are indeed correctly understood. But when there are officially stated rules, from authorities that have jurisdiction, those are the ones to use even if some real-world users don't follow those rules. Otherwise we get to the point where your timezone is a matter of opinion, which is a lack of principle all too prevalent in too many other human activities... paul

On 26 May 2016 at 17:19, Deborah Goldsmith <goldsmit@apple.com> wrote:

My understanding was that the TZ database reflected what users are actually doing, rather than what government policy is. Has that changed?

No, but the TZ database only cares that there exist a set of people/places who use Mountain Time with DST (America/Denver) and a separate set of people/places who use Mountain Time without DST (America/Phoenix). It has never really concerned itself with where any borders between those regions are, no matter how simple or complex. However, if there were a historical case where a region once observing DST decided to stop, or a region once not using DST decided to start, then that would be codified as a new zone, since the rulesets would differ from both America/Denver and America/Phoenix. But perhaps if only a small handful of people are affected by these effective border changes, it *may* be too insignificant to bother. -- Tim Parenti

At 10:53 PM 5/24/2016, Brian Inglis wrote:

Federal facilities and areas within AZ are subject to federal legislation so they too observe DST.

Federal legislation deals with time zone borders, not DST observance. DST observance is a state (and Indian) matter. Only AZ and HI have decided not to observe. Federal facilities located in those states therefore do not observe DST. Everything from national parks to post offices to federal polling places. Indian nations are deemed to have similar authority - and that it supersedes that of the state in which they are located. So on reservation lands the Navajo decision to observe DST trumps the AZ decision not to. Federal facilities inside the Navajo reservation observe time per the Navajo authority instead of the AZ authority. There are also exceptions to federal facilities deviating from official local time. The only one I knew of before today was Guadalupe Mountains National Park, which observes Mountain time despite being mostly located in the Central time zone. Today I learned of the Dangling Rope Marina exception. Regards, Steve Jones Emacs!