America/Metlakatla now follows Alaska
It seems Metlakatla did go off PST on Sunday, November 1, changing their time to AKST and are going to follow Alaska's DST, switching between AKST and AKDT from now on. Based on: http://www.krbd.org/2015/10/30/annette-island-times-they-are-a-changing/ Best regards, Steffen Thorsen - timeanddate.com
Thanks for the heads-up. Proposed patch attached. We'll need a new release of course, but this does not seem to be urgent.
Interesting. I wonder what they will do if/when the bill to abolish DST in Alaska passes into law? Will they stay on UTC-9 or go back to UTC-8? Only time will tell. Also, while researching, I stumbled across something interesting: http://juneauempire.com/opinion/2015-11-05/empire-editorial-daylight-saving-time-necessary-inconvenience"Metlakatla is on Pacific Time (unofficially, Hyder is, too)" I hadn't heard of Hyder in the tzdb, so digging a little deeper: https://en.wikipedia.org/wiki/Hyder,_Alaska#Canadian_and_British_Columbian_influence_on_culture"Tourists also find that Hyder uses the Pacific Time Zone" https://en.wikipedia.org/wiki/Pacific_Time_Zone#United_States"The town of Hyder, Alaska, is officially in the Alaska Time Zone. However, most of the town observes the Pacific Time because of strong connections with nearby Stewart, British Columbia, which is in the Pacific Time Zone. The United States Post Office in Hyder strictly adheres to Alaska Time." https://en.wikivoyage.org/wiki/Hyder"Unlike the rest of Alaska, Hyder unofficially uses the Pacific Time Zone like most of British Columbia and the US West Coast States." http://www.mytripjournal.com/travel-751992-post-office-british-columbia-time-zone-hyder-alaska"All of Alaska is on the Alaska time zone except Hyder which is on the same time zone as British Columbia. Except for the post office that is. Inside the post office is one hour different from the time out in the street." https://seagrant.uaf.edu/nosb/papers/2003/chugiak-ginseng.html"Another factor which makes business in Hyder difficult is the time zone. While Hyder is technically within the Alaska Time Zone, all of the residents of Hyder set their clocks one hour later so as to comply with the Pacific Time Zone as used by their Canadian neighbors. This can make dealing with the rest of the state more difficult because one hour is lost during each business day due to this discrepancy." https://books.google.com/books?id=c-IGSXX7_n0C&pg=PA167&dq=time+zone"Hyder residents ... use the Candaian time zone ... and are on a different time zone than the rest of Alaska" The only discrepancy I found is:https://books.google.com/books?id=oWNpEz74fm0C&pg=PA158&dq=time+zone"... But it does stay in the Alaskan time zone. A little confusing, but not enough to matter." That one is dated August 11-12, 1997 - so perhaps sometime after that. The other book is dated 2002, so sometime between. I couldn't find confirmation of whether they use DST or not, but I assume that since they match nearby Stewart, BC, which should be on America/Vancouver, that they do. Should there be an America/Hyder zone entry? -Matt
To: tz@iana.org From: thorsen@timeanddate.com Date: Mon, 9 Nov 2015 14:34:37 +0100 Subject: [tz] America/Metlakatla now follows Alaska
It seems Metlakatla did go off PST on Sunday, November 1, changing their time to AKST and are going to follow Alaska's DST, switching between AKST and AKDT from now on.
Based on: http://www.krbd.org/2015/10/30/annette-island-times-they-are-a-changing/
Best regards, Steffen Thorsen - timeanddate.com
At 11:51 AM 11/9/2015, Matt Johnson wrote:
Should there be an America/Hyder zone entry?
Hyder does observe Daylight Saving time. http://ontimezone.com/exceptions.php "AK: Hyder Alaska unofficially observes Pacific time, even though they are officially in the Alaska time zone. But the post office, being a federal facility, is on Alaska time." But it is an unofficial exception, similar to all of these: Guadapupe Mountains National Park, Texas Winterhaven, CA Earp, CA Jackpot, NV Jarbidge, NV Owyhee, Mountain City, and the Duck Valley Indian Reservation, NV Kenton Oklahoma Nara Visa, New Mexico Phenix City Alabama Valley/Lanett Alabama Fort Pierre South Dakota All of which are documented at the OnTimeZone.com exceptions page, which also contains this note:
Near official time zone borders, there are sometimes unnoficial exceptions where locally observed time differs. The main borders in OnTimeZone.com normally follow the observed time - which is what a traveler is likely to actually encounter.
Unofficial "observed" differences usually follow vague areas of economic or political influence which defy precise definition. But we had to draw them somewhere. Often these borders are in lightly settled areas. We took pains to draw them on the correct side of roads, businesses, services and populated settlements. That was our intent anyway - corrections appreciated!
Wherever these areas are in the US, unofficial borders are drawn in lime green, with the official alternative drawn in dark green. No attempt was made to do this for other countries, because distinctions between official and unofficial blur a bit in the various political subdivisions. In the US all official time zone borders are well and clearly documented by a single source - the US Dept. of Transportation.
Within an area where observed practice differs from official, there are often internal exceptions. Possible examples are polling places, post offices or other federal offices -- and sometimes law enforcement or various other governmental entities which may observe official time.
Bars or liquor stores in these areas are often required by law to observe official time. This can provide quite an advantage for properly situated bars, when last-call sojourners migrate across an official time zone border to cadge one more hour of bliss.
I have no idea if there should be entries for such unofficial exceptions, but I assume it should be all or none. Regards, Steve Jones Emacs!
Steve Jones <stevejones@OnTimeZone.com> writes:
I have no idea if there should be entries for such unofficial exceptions, but I assume it should be all or none.
Not all of these have their own entries because many of them are served well enough by the official zone that they match (for example, pockets of Indiana that observed EDT unofficially prior to 2006 are served by America/New_York or America/Louisville). As far as I know, tzdb's policy is to have the "borders" of each zone exclusively follow de facto observance, without any distinction between "officially A, unofficially B" vs the bulk of the "B" zone, unless the situation changed some time between 1970 and now.
At 02:36 PM 11/9/2015, Random832 wrote:
As far as I know, tzdb's policy is to have the "borders" of each zone exclusively follow de facto observance, without any distinction between "officially A, unofficially B" vs the bulk of the "B" zone, unless the situation changed some time between 1970 and now.
Interesting. For areas that have such unofficial deviations, there can be great discrepancy in the scope of observance, geographically and otherwise. For example, it US Federal facilities rarely observe an unofficial time zone. But there are exceptions - such as the Guadalupe Mountains National Park. Even local government may set their clocks to official time - but not always. City hall offices in Phenix City AL are set to Eastern Time. And where the lines get fuzzy, where the economic or social influence that led to the exception wanes, two next door neighbors may have their clocks set differently depending on where the most of the bread in that household is won or spent. When researching Fort Pierre SD I had one knowledgeable local resource tell me the observance extended about 50 miles west of the city. Another equally knowledgeable local insisted it was no more than 20 miles. So I guess that raises the question, what really *is* de facto observance. Regardless, I believe all of the exceptions I listed, and Hyder, predate 1970. Regards, Steve Jones Emacs!
I can add one small data point to Hyder's time zone history. In 1974, my brother and I took a road trip. Part of our itinerary was the Stewart-Cassiar Highway. On July 5, 1974, we walked from Stewart, B.C. across the border to the First Chance Cafe in Hyder, Alaska, no more than a mile. According to my brother's journals, Hyder was using PDT, just like Stewart. Gwillim Law On Mon, Nov 9, 2015 at 5:14 PM, Steve Jones <stevejones@ontimezone.com> wrote:
[...] Regardless, I believe all of the exceptions I listed, and Hyder, predate 1970.
Hi Folks - we do IT for the school in Metlakatla. How long does it take once the patch is made for it to filter out to servers? The town let us know about the change after they made the decision so we didn't have a chance to prepare. Many of the devices are set to use location to determine timezone, so we're looking forward to Metlakatla's info being updating in participating servers (namely Apple's). - Ryan _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ AKTechOps <http://serrc.org/techops> | techops@serrc.org | 907.523.7290 On Mon, Nov 9, 2015 at 8:51 AM, Matt Johnson <mj1856@hotmail.com> wrote:
Interesting. I wonder what they will do if/when the bill to abolish DST in Alaska passes into law? Will they stay on UTC-9 or go back to UTC-8? Only time will tell.
Also, while researching, I stumbled across something interesting:
http://juneauempire.com/opinion/2015-11-05/empire-editorial-daylight-saving-... *"Metlakatla is on Pacific Time (unofficially, Hyder is, too)"*
I hadn't heard of Hyder in the tzdb, so digging a little deeper:
https://en.wikipedia.org/wiki/Hyder,_Alaska#Canadian_and_British_Columbian_i... *"Tourists also find that Hyder uses the Pacific Time Zone"*
https://en.wikipedia.org/wiki/Pacific_Time_Zone#United_States *"The town of Hyder, Alaska, is officially in the Alaska Time Zone. However, most of the town observes the Pacific Time because of strong connections with nearby Stewart, British Columbia, which is in the Pacific Time Zone. The United States Post Office in Hyder strictly adheres to Alaska Time."*
https://en.wikivoyage.org/wiki/Hyder *"Unlike the rest of Alaska, Hyder unofficially uses the Pacific Time Zone like most of British Columbia and the US West Coast States."*
http://www.mytripjournal.com/travel-751992-post-office-british-columbia-time... *"All of Alaska is on the Alaska time zone except Hyder which is on the same time zone as British Columbia. Except for the post office that is. Inside the post office is one hour different from the time out in the street."*
https://seagrant.uaf.edu/nosb/papers/2003/chugiak-ginseng.html *"Another factor which makes business in Hyder difficult is the time zone. While Hyder is technically within the Alaska Time Zone, all of the residents of Hyder set their clocks one hour later so as to comply with the Pacific Time Zone as used by their Canadian neighbors. This can make dealing with the rest of the state more difficult because one hour is lost during each business day due to this discrepancy."*
https://books.google.com/books?id=c-IGSXX7_n0C&pg=PA167&dq=time+zone *"Hyder residents ... use the Candaian time zone ... and are on a different time zone than the rest of Alaska"*
The only discrepancy I found is: https://books.google.com/books?id=oWNpEz74fm0C&pg=PA158&dq=time+zone *"... But it does stay in the Alaskan time zone. A little confusing, but not enough to matter."*
That one is dated August 11-12, 1997 - so perhaps sometime after that. The other book is dated 2002, so sometime between.
I couldn't find confirmation of whether they use DST or not, but I assume that since they match nearby Stewart, BC, which should be on America/Vancouver, that they do.
Should there be an America/Hyder zone entry?
-Matt
To: tz@iana.org From: thorsen@timeanddate.com Date: Mon, 9 Nov 2015 14:34:37 +0100 Subject: [tz] America/Metlakatla now follows Alaska
It seems Metlakatla did go off PST on Sunday, November 1, changing their time to AKST and are going to follow Alaska's DST, switching between AKST and AKDT from now on.
Based on: http://www.krbd.org/2015/10/30/annette-island-times-they-are-a-changing/
Best regards, Steffen Thorsen - timeanddate.com
On Nov 10, 2015, at 9:06 AM, TechOps <techops@serrc.org> wrote:
Hi Folks - we do IT for the school in Metlakatla. How long does it take once the patch is made for it to filter out to servers?
Your servers, or somebody else's servers? For your own servers, for the system's tzdb files: If your system has zic on it, and you download the updated files and run zic on them, it takes as long as it takes you to do that. :-) zic should install them in the official system locations for compiled tzdb files by default. If you don't have zic on your system, or you don't download them and run zic on them, but wait for the vendor to provide an update, it takes however long it takes that vendor to make such an update; we can't tell you how long that'd be, the vendor would have to do that. If the vendor has a mechanism to provide updates very quickly, as, for example, some (perhaps most) Linux distributions do (Ubuntu and Fedora, for example, don't seem to have dot-dot releases, they just update individual components as necessary), that could happen quickly. If they don't have such a mechanism, it could take longer. That will update the system's files; if some other software on your system has its own compiled files, you'd have to figure out where they are and replace them, or wait for the vendor to provide an update. For somebody else's servers, those questions all apply, except that you don't get to install the updated files yourself, so it depends on their vendors *and* their own internal IT organization.
The town let us know about the change after they made the decision so we didn't have a chance to prepare. Many of the devices are set to use location to determine timezone, so we're looking forward to Metlakatla's info being updating in participating servers (namely Apple's).
"Apple's" as in "you have Macs running OS X and OS X Server at your school, and you want updates for those local servers", or "Apple's" as in "Apple's own servers for iTunes and iCloud and so on"?
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. Basically I'm wondering what the standard trickle-down duration is... days, weeks, or months. _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ AKTechOps <http://serrc.org/techops> | techops@serrc.org | 907.523.7290 On Tue, Nov 10, 2015 at 8:47 AM, Guy Harris <guy@alum.mit.edu> wrote:
On Nov 10, 2015, at 9:06 AM, TechOps <techops@serrc.org> wrote:
Hi Folks - we do IT for the school in Metlakatla. How long does it take once the patch is made for it to filter out to servers?
Your servers, or somebody else's servers?
For your own servers, for the system's tzdb files:
If your system has zic on it, and you download the updated files and run zic on them, it takes as long as it takes you to do that. :-) zic should install them in the official system locations for compiled tzdb files by default.
If you don't have zic on your system, or you don't download them and run zic on them, but wait for the vendor to provide an update, it takes however long it takes that vendor to make such an update; we can't tell you how long that'd be, the vendor would have to do that. If the vendor has a mechanism to provide updates very quickly, as, for example, some (perhaps most) Linux distributions do (Ubuntu and Fedora, for example, don't seem to have dot-dot releases, they just update individual components as necessary), that could happen quickly. If they don't have such a mechanism, it could take longer.
That will update the system's files; if some other software on your system has its own compiled files, you'd have to figure out where they are and replace them, or wait for the vendor to provide an update.
For somebody else's servers, those questions all apply, except that you don't get to install the updated files yourself, so it depends on their vendors *and* their own internal IT organization.
The town let us know about the change after they made the decision so we didn't have a chance to prepare. Many of the devices are set to use location to determine timezone, so we're looking forward to Metlakatla's info being updating in participating servers (namely Apple's).
"Apple's" as in "you have Macs running OS X and OS X Server at your school, and you want updates for those local servers", or "Apple's" as in "Apple's own servers for iTunes and iCloud and so on"?
On Nov 10, 2015, at 10:12 AM, TechOps <techops@serrc.org> wrote:
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.
You're assuming that what servers are involved there, if any, need to have the time zone rules up to date. As far as I know, setting the time zone based on location is done by: 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: https://en.wikipedia.org/wiki/Wi-Fi_positioning_system 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. 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. The second of those might involve servers to map a location to a tzdb zone, but 1) it might not, if the maps are stored on the machine; 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. 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*.
Basically I'm wondering what the standard trickle-down duration is... days, weeks, or months.
Well, as I said, it needs to trickle down to your machines, not to the servers. 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 1) how long it takes Apple to get a tzdb release into an OS dot-dot release; 2) how long it takes that release to come out, as it has a lot more in it than just a tzdb update. 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.
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). https://en.wikipedia.org/wiki/NITZ 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. 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. -Matt -----Original Message----- From: tz-bounces@iana.org [mailto:tz-bounces@iana.org] On Behalf Of Guy Harris Sent: Tuesday, November 10, 2015 10:41 AM To: TechOps <techops@serrc.org> Cc: Time Zone Database <tz@iana.org> Subject: Re: [tz] America/Metlakatla now follows Alaska On Nov 10, 2015, at 10:12 AM, TechOps <techops@serrc.org> wrote:
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.
You're assuming that what servers are involved there, if any, need to have the time zone rules up to date. As far as I know, setting the time zone based on location is done by: 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: https://na01.safelinks.protection.outlook.com/?url=https%3a%2f%2fen.wikipedi... 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. 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. The second of those might involve servers to map a location to a tzdb zone, but 1) it might not, if the maps are stored on the machine; 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. 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*.
Basically I'm wondering what the standard trickle-down duration is... days, weeks, or months.
Well, as I said, it needs to trickle down to your machines, not to the servers. 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 1) how long it takes Apple to get a tzdb release into an OS dot-dot release; 2) how long it takes that release to come out, as it has a lot more in it than just a tzdb update. 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.
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. _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ AKTechOps <http://serrc.org/techops> | techops@serrc.org | 907.523.7290 On Tue, Nov 10, 2015 at 10:49 AM, Matt Johnson (PNP) < matt.johnson@microsoft.com> wrote:
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). https://en.wikipedia.org/wiki/NITZ
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.
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.
-Matt
-----Original Message----- From: tz-bounces@iana.org [mailto:tz-bounces@iana.org] On Behalf Of Guy Harris Sent: Tuesday, November 10, 2015 10:41 AM To: TechOps <techops@serrc.org> Cc: Time Zone Database <tz@iana.org> Subject: Re: [tz] America/Metlakatla now follows Alaska
On Nov 10, 2015, at 10:12 AM, TechOps <techops@serrc.org> wrote:
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.
You're assuming that what servers are involved there, if any, need to have the time zone rules up to date.
As far as I know, setting the time zone based on location is done by:
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:
https://na01.safelinks.protection.outlook.com/?url=https%3a%2f%2fen.wikipedi...
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.
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.
The second of those might involve servers to map a location to a tzdb zone, but
1) it might not, if the maps are stored on the machine;
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.
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*.
Basically I'm wondering what the standard trickle-down duration is... days, weeks, or months.
Well, as I said, it needs to trickle down to your machines, not to the servers.
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
1) how long it takes Apple to get a tzdb release into an OS dot-dot release;
2) how long it takes that release to come out, as it has a lot more in it than just a tzdb update.
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.
On Tue, 10 Nov 2015, TechOps wrote:
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.
Don't forget to keep in touch, and let this list know if any future changes are proposed. It's always better for us to find out as soon as possible, when changes are being contemplated or debated, rather than after the change is done. +------------------+--------------------------+-------------------------+ | Paul Goyette | PGP Key fingerprint: | E-mail addresses: | | (Retired) | FA29 0E3B 35AF E8AE 6651 | paul at whooppee.com | | Kernel Developer | 0786 F758 55DE 53BA 7731 | pgoyette at netbsd.org | +------------------+--------------------------+-------------------------+
On Nov 10, 2015, at 11:49 AM, Matt Johnson (PNP) <matt.johnson@microsoft.com> wrote:
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). https://en.wikipedia.org/wiki/NITZ
He'd asked about iPads and Macs, both of which definitely *do* use the location information, but, yes, some machines might not do so. (One would hope that devices with 1) the ability to determine the device location, 2) OSes of a sufficient level of sophistication - which includes both UN*Xes and Windows NT derivatives - and 3) enough space to spend some of it on a set of boundaries for the OS's notion of time zones, would use the location information.)
On 11/10/2015 10:12 AM, TechOps wrote:
Basically I'm wondering what the standard trickle-down duration is... days, weeks, or months.
In the past, the answer has been "months", because it takes time to publish a new tz package, more time to get the upstream vendors to apply it, still more time to get this to trickle through to downstream suppliers, and so forth. We're trying to encourage everybody to get it down to "weeks" but we're not there yet. So even if we were to publish a new tz package today, it'd take months for it to propagate to many devices. In the meantime, you can set your timezone to Alaska/Anchorage, or set your location to that of Anchorage, and that should work around the problem. For example, if you using Google Chrome or Firefox, you can fake your location as follows: http://www.baatkar.com/2015/04/how-to-fake-your-location-in-google.html For a more-interesting approach you can do what Netflix pirates do when they bypass geolocation checking, but this will put you on thin ice.
On Nov 10, 2015, at 10:51 AM, Paul Eggert <eggert@cs.ucla.edu> wrote:
On 11/10/2015 10:12 AM, TechOps wrote:
Basically I'm wondering what the standard trickle-down duration is... days, weeks, or months.
In the past, the answer has been "months", because it takes time to publish a new tz package, more time to get the upstream vendors to apply it, still more time to get this to trickle through to downstream suppliers, and so forth. We're trying to encourage everybody to get it down to "weeks" but we're not there yet. So even if we were to publish a new tz package today, it'd take months for it to propagate to many devices.
The next trains to leave Apple Station are iOS 9.2 and OS X 10.11.2. I don't know whether the updates will make it into those releases, or when they'll be released (as I noted in my previous mail, they include a number of changes unrelated to time zones, so they'll have to wait for those changes to be beta-tested and finalized).
In the meantime, you can set your timezone to Alaska/Anchorage, or set your location to that of Anchorage, and that should work around the problem.
For iOS, open up the Settings app, select "General", select "Date & Time", turn off "Set Automatically", type "anchorage" into the text box to get "Anchorage, U.S.A.", and select that. For OS X, open up the System Preferences app, select "Date & Time", select "Time Zone", run off "Set time zone automatically using current location", type "anchorage" into the "Closest City" box to get "Anchorage, AK - United States", and use that.
On Nov 10, 2015, at 12:06 PM, TechOps <techops@serrc.org> wrote:
Hi Folks - we do IT for the school in Metlakatla. How long does it take once the patch is made for it to filter out to servers? The town let us know about the change after they made the decision so we didn't have a chance to prepare.
This might be an opportunity to remind the politicians that these changes can't be made instantly. In other words, the pain caused to everyone else by the wrong timestamps is entirely their fault, and easily avoidable. paul
This might be an opportunity to remind the politicians that these changes can't be made instantly. In other words, the pain caused to everyone else by the wrong timestamps is entirely their fault, and easily avoidable.
+1. Deborah
On Nov 10, 2015, at 10:09 AM, Paul_Koning@Dell.com wrote:
On Nov 10, 2015, at 12:06 PM, TechOps <techops@serrc.org> wrote:
Hi Folks - we do IT for the school in Metlakatla. How long does it take once the patch is made for it to filter out to servers? The town let us know about the change after they made the decision so we didn't have a chance to prepare.
This might be an opportunity to remind the politicians that these changes can't be made instantly. In other words, the pain caused to everyone else by the wrong timestamps is entirely their fault, and easily avoidable.
paul
participants (12)
-
Deborah Goldsmith -
Guy Harris -
Gwillim Law -
Matt Johnson -
Matt Johnson (PNP) -
Paul Eggert -
Paul Goyette -
Paul_Koning＠dell.com -
Random832 -
Steffen Thorsen -
Steve Jones -
TechOps