<div dir="ltr"><div class="gmail_default" style="font-size:small">thanks for the great info all! And yea, I'm not sure town leadership thought they'd have to do more than just change their clocks.<br></div><div class="gmail_default" style="font-size:small"><br></div><div class="gmail_default" style="font-size:small"><br></div></div><div class="gmail_extra"><br clear="all"><div><div class="gmail_signature">_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _<br><a href="http://serrc.org/techops" target="_blank">AKTechOps</a> | <a href="mailto:techops@serrc.org" target="_blank">techops@serrc.org</a> | 907.523.7290</div></div>
<br><div class="gmail_quote">On Tue, Nov 10, 2015 at 10:49 AM, Matt Johnson (PNP) <span dir="ltr"><<a href="mailto:matt.johnson@microsoft.com" target="_blank">matt.johnson@microsoft.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Also keep in mind that a large number of mobile devices (esp. phones) do not actually use the device's location information to set the time zone, but rather use the signals provided by the mobile carrier (such as NITZ).<br>
<a href="https://en.wikipedia.org/wiki/NITZ" rel="noreferrer" target="_blank">https://en.wikipedia.org/wiki/NITZ</a><br>
<br>
These settings differ for individual cell towers and can sometimes be inaccurate, as they send only the current standard time offset from utc, and a DST offset if and when DST is in effect.<br>
<br>
You could find out which mobile carriers have cell towers in the area and ask them to update the time zone to include the DST offset. Doing so would likely cause phones that use these signals to pick Alaskan time.<br>
<br>
-Matt<br>
<span class=""><br>
-----Original Message-----<br>
From: <a href="mailto:tz-bounces@iana.org">tz-bounces@iana.org</a> [mailto:<a href="mailto:tz-bounces@iana.org">tz-bounces@iana.org</a>] On Behalf Of Guy Harris<br>
Sent: Tuesday, November 10, 2015 10:41 AM<br>
To: TechOps <<a href="mailto:techops@serrc.org">techops@serrc.org</a>><br>
Cc: Time Zone Database <<a href="mailto:tz@iana.org">tz@iana.org</a>><br>
Subject: Re: [tz] America/Metlakatla now follows Alaska<br>
<br>
<br>
On Nov 10, 2015, at 10:12 AM, TechOps <<a href="mailto:techops@serrc.org">techops@serrc.org</a>> wrote:<br>
<br>
> thanks for the reply Guy, and sorry for being vague. By Apple's servers I mean whatever servers reply to an out-of-the-box iPad or Mac when it tries to set its timezone based on location.<br>
<br>
You're assuming that what servers are involved there, if any, need to have the time zone rules up to date.<br>
<br>
As far as I know, setting the time zone based on location is done by:<br>
<br>
the machine using Location Services to find out where it is - that's done using GPS if it's available, and otherwise done, I think, by looking around for Wi-Fi access points and figuring out where you are based on that:<br>
<br>
</span> <a href="https://na01.safelinks.protection.outlook.com/?url=https%3a%2f%2fen.wikipedia.org%2fwiki%2fWi-Fi_positioning_system&data=01%7c01%7cmatt.johnson%40microsoft.com%7ca58ed9d6211d4fbc46e808d2e9fea391%7c72f988bf86f141af91ab2d7cd011db47%7c1&sdata=5ahoEDDu%2bx%2bkNlftdyzdwScRvUw%2bQmWKk%2bwowRRDgNY%3d" rel="noreferrer" target="_blank">https://na01.safelinks.protection.outlook.com/?url=https%3a%2f%2fen.wikipedia.org%2fwiki%2fWi-Fi_positioning_system&data=01%7c01%7cmatt.johnson%40microsoft.com%7ca58ed9d6211d4fbc46e808d2e9fea391%7c72f988bf86f141af91ab2d7cd011db47%7c1&sdata=5ahoEDDu%2bx%2bkNlftdyzdwScRvUw%2bQmWKk%2bwowRRDgNY%3d</a><br>
<div class="HOEnZb"><div class="h5"><br>
the machine then looking up that location in a set of maps of tzdb zone boundaries, which might be stored on the machine or might be obtained from a server.<br>
<br>
The first of those operations only involves servers for the Wi-Fi mechanism, and doesn't involve time zones at all, only a database of Wi-Fi networks, so *those* servers don't need to be updated.<br>
<br>
The second of those might involve servers to map a location to a tzdb zone, but<br>
<br>
1) it might not, if the maps are stored on the machine;<br>
<br>
2) even if it does, only a tzdb change involving changes to zone boundaries, including the creation of a new tzdb zone, would have to get propagated to the server.<br>
<br>
OS X, iOS, tvOS, and any other Darwin-based OSes from Apple all use the tzdb internally, so it's not the servers that need updating, it's the OS on the *clients*.<br>
<br>
> Basically I'm wondering what the standard trickle-down duration is... days, weeks, or months.<br>
<br>
Well, as I said, it needs to trickle down to your machines, not to the servers.<br>
<br>
There's no standard duration for Apple's OSes, as they're currently not set up to provide tzdb updates outside of software updates, so the trickle-down duration (the time between a tzdb release and its appearance in a Darwin-based OS) depends on<br>
<br>
1) how long it takes Apple to get a tzdb release into an OS dot-dot release;<br>
<br>
2) how long it takes that release to come out, as it has a lot more in it than just a tzdb update.<br>
<br>
Note also that if the machine isn't running an OS that gets updates that include tzdb updates, it won't get updated. I don't know whether they are included in security updates, but, if they don't, you won't get updates for Macs running anything other than El Capitan, and I don't know whether iOS gets security updates for major releases before the current release, so machines running iOS 8 or earlier may not get updates.<br>
</div></div></blockquote></div><br></div>