[tz] Anecdotal discrepancy for Navajo nation in Arizona

[Guy Harris]

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

> 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"?

OK, it's 3GPP TS 24.008 that's the key here; section 9.2.15a "MM information" and section 9.4.19 "GMM Information" in version 12.11.0 Release 12 speak of "Universal time and local time zone" and "Network Daylight Saving Time" information elements.

That spec has:

	section 10.5.3.8 "Time Zone", describing an information element giving "the offset between universal time and local time in steps of 15 minutes";

	section 10.5.3.9 "Time Zone and Time", describing an information element giving "the universal time at which this information element may have been sent by the network" and "the offset between universal time and local timein steps of 15 minutes";

	section 10.5.3.12 "Daylight Saving Time", describing an information element giving "Daylight Saving Time in steps of 1 hour", as in one of "No adjustment for Daylight Saving Time", "+1 hour adjustment for Daylight Saving Time", and "+2 hours adjustment for Daylight Saving Time";

so if you're going to get a tzdb tzid from that, I guess you'll have to search for a tzdb file that says that, for some appropriate time corresponding to, as best can be determined, the time corresponding when the message containing the information elements in question was sent (which you might have to approximate with the time when it was received), the offset between UTC and local time is the time zone value and the DST offset is the DST offset value from the information elements in question.

I guess if you don't find any such tzdb file, you either have to go by location and maps, or do something probably less sensible.

So:

	1) Is that what iOS, at least, does?  (I guess OS X could do it *if* the machine has some mobile phone modem plugged into it *and* that mobile phone modem can supply information from those messages to the host.)

	2) Does the tzdb file found by a search based on NITZ take precedence over the tzdb file found by using Core Location information?

	3) What happens if you happen to be using a cell site that's on the other side of a "time zone region" border, so that the cell site gives you NITZ information that doesn't correspond to your actual geographical location?