On 2016-12-04 07:24, Juan Correa wrote:

There is no official decree published yet, but it has been reported by official Chilean government Twitter accounts that Magallanes región (https://en.wikipedia.org/wiki/Magallanes_Region) will keep DST (UTC -3) all year round Sources: - https://twitter.com/presidencia_cl/status/805398903604576256 (from Press Office of the Presidency of Chile, "President Michelle Bachelet signs the decree that establishes a single timezone for Magallanes región") - https://twitter.com/AndresReboll/status/805398964690386944 (from Minister of Energy, "after a participative (sic) process and thoughtful investigation, decided to establish a single timezone (*summer*) for Magallanes) - http://www.soychile.cl/Santiago/Sociedad/2016/12/04/433428/Bachelet-firmo-el... As a reminder, Chile has (since 2016) DST from August to May following year The biggest city in the region is Punta Arenas, with over 123 thousand inhabitants. The whole population for Magallanes region is 164.661 people As soon as the decree gets published, I'll share it here

May be helpful in zone.tab or comments to mention provinces impacted: Magallanes, Última Esperanza, Tierra del Fuego, Antártica Chilena (in order by population) https://en.wikipedia.org/wiki/Magallanes_Region#Provinces_and_communes -- Take care. Thanks, Brian Inglis, Calgary, Alberta, Canada

Dear Paul, we suggest two names: America/PuntaArenas (main city of region) Chile/Magallanes (region name, according to Chile directory name structure) Regards/Saludos ----- Mensaje original ----- De: "Paul Eggert" <eggert@cs.ucla.edu> Para: "Juan Correa" <pottersys@gmail.com> CC: "Time zone mailing list" <tz@iana.org> Enviados: Lunes, 5 de Diciembre 2016 5:47:10 Asunto: Re: [tz] Magallanes region from Chile will keep DST all year round Thanks for the heads-up. This also affects Antarctica/Palmer. Proposed patch attached. Although we might need to tweak the transition date once the official decree is published, I don't see that affecting the clocks. This change does not appear to be urgent, as clocks aren't affected until 2017-05-13. Brian Inglis wrote:

May be helpful in zone.tab or comments to mention provinces impacted: Magallanes, Última Esperanza, Tierra del Fuego, Antártica Chilena

That's a bit long, so the proposed patch uses "Region of Magallanes", which contains those provinces.

Hi, Apparently, this became official on Tuesday: http://www.diariooficial.interior.gob.cl/publicaciones/2017/01/17/41660/01/1... It would be great to get a tz update with these changes in the next week or so. Thanks, Debbie

On Dec 5, 2016, at 9:53 AM, Paul Eggert <eggert@CS.UCLA.EDU> wrote:

On 12/05/2016 04:19 AM, Eduardo Romero Urra wrote:

...

America/PuntaArenas (main city of region) Chile/Magallanes (region name, according to Chile directory name structure)

Thanks, the current proposal has America/Punta_Arenas. The links Chile/Continental and Chile/EasterIsland are present only for backward compatibility, and I'd rather not add another Chile/* name. It's like America/Boise, which doesn't have a US/* backward-compatibility link because America/Boise also was added after the Great Renaming.

Juan Correa wrote:

the decree says "Magallanes region shall be on DST until May 2019 transition"

If we interpret the decree modification as written, Magallanes is scheduled to change from -03 to -04 on 2019-05-11 at 24:00, which will be one hour after Santiago is scheduled to change from -03 to -04. Surely this is not intended. For now, it's simpler to assume the change will be permanent, or at least as permanent as anything regarding clocks in Chile. Proposed patch attached. I've installed this patch into the development repository on GitHub, and anybody who needs the Magallanes change now can use that repository. I'm reluctant to generate a new tz version just for this, as it's far enough in the future that it's likely we'll need to generate a new release for other reasons anyway.

Aside, I hope the new official version goes live around Feb. 15 in the worst case; so downstream providers (and developers) can test this new time zone without being in a hurry

Since this involves a new time zone, and thus requires changes in other databases (localization, time zone polygons), the lead time needs to be longer than usual. Now that the change is finalized, please release this. Work on the other databases is stalled until that happens. Distributing an intermediate version from the GitHub repository is problematic because calling it either 2016j or 2017a are both incorrect. Downstream providers would have to make up an identifier which wouldn’t be cross-platform, and could cause problems with software that wasn’t expecting it. Debbie

On Jan 19, 2017, at 8:28 PM, Juan Correa <pottersys@gmail.com> wrote:

On Fri, Jan 20, 2017, Paul Eggert <eggert@cs.ucla.edu <mailto:eggert@cs.ucla.edu>> wrote: If we interpret the decree modification as written, Magallanes is scheduled to change from -03 to -04 on 2019-05-11 at 24:00, which will be one hour after Santiago is scheduled to change from -03 to -04. Surely this is not intended. For now, it's simpler to assume the change will be permanent

Both Magallanes and Santiago will be on UTC -03 for this 2019 scheduled transition (Santiago shall start DST [-04 to -03] on Aug 11, 2018); so they will jump back to -04 simultaneously *if they don't change this again* (and it will jump to "hora oficial" [Santiago] nevertheless that day)

I tested the patch, and it works OK for this year.

Aside, I hope the new official version goes live around Feb. 15 in the worst case; so downstream providers (and developers) can test this new time zone without being in a hurry

-- Juan Correa Poblete PS Labs (http://www.pslabs.cl <http://www.pslabs.cl/>)

On 2017-01-20 03:27, Paul Eggert wrote:

If we interpret the decree modification as written, Magallanes is scheduled to change from -03 to -04 on 2019-05-11 at 24:00, which will be one hour after Santiago is scheduled to change from -03 to -04. Surely this is not intended. For now, it's simpler to assume the change will be permanent, or at least as permanent as anything regarding clocks in Chile. Proposed patch attached.

I've installed this patch into the development repository on GitHub, and anybody who needs the Magallanes change now can use that repository. I'm reluctant to generate a new tz version just for this, as it's far enough in the future that it's likely we'll need to generate a new release for other reasons anyway.

While it is still experimental -- the reference in the proposed patch gives the date 2016-12-02 for the decree, so in the Zone entries for Punta Arenas and Palmer station : - -4:00 Chile -04/-03 2016 Dec 4 + -4:00 Chile -04/-03 2016 Dec 2 Michael Deckers.

On 01/23/2017 03:55 PM, Deborah Goldsmith wrote:

This also requires getting the ICU team to release updated metazone data for an unreleased IANA snapshot. This is a lot of work on multiple people’s parts to save having to turn the crank on a TZ release.

Many different cranks have to be turned whenever a new TZ release is made, not only by IANA but also by downstream developers and distributors. Surely this is more work overall than a one-time minor change to ICU's procedure so that they can base their effort on tz snapshot Y instead of release X.

On 01/23/2017 04:35 PM, Deborah Goldsmith wrote:

If it’s unimportant to release this change early, why can’t people just wait before they turn the crank if they don’t care about it?

Because it takes work to decide whether to wait. We've had a longstanding tradition to not release tzdb versions merely because of trivial or non-urgent changes, based on the principle that we often get short notice anyway and so any redistribution should work on short notice, and that omitting unnecessary releases saves everybody time. If we started to release more often, we would in effect be asking every downstream developer and distributor to inspect every release and decide whether that release's changes are important and urgent enough for them to update. If the problem is that ICU won't look at tzdata except just after an "official" tzdb release and that the ICU folks then take some time to do translations and that Apple won't use the new tzdb update until after ICU has done their translations, then that leisurely process needs to be streamlined regardless of tzdb's version numbering scheme. If this diagnosis is correct, I suggest that Apple work with ICU to have a more incremental process where ICU does not wait until an "official" tzdb release before starting work on translating changes. This should not involve any major technical change on ICU's side (they merely need to use version 2016j-38-g46c2bbf instead of version 2016j, say). ICU will have to track tzdb more closely, but that will be true no matter what version-numbering scheme is used. The main problem here is the delay in downstream translation, not in whether the current tzdb version is called '2016j-38-g46c2bbf' or '2017a'.

On 2017-01-24 09:32, Paul Eggert wrote:

On 01/23/2017 04:35 PM, Deborah Goldsmith wrote:

...

If it’s unimportant to release this change early, why can’t people just wait before they turn the crank if they don’t care about it?

Because it takes work to decide whether to wait. We've had a longstanding tradition to not release tzdb versions merely because of trivial or non-urgent changes, based on the principle that we often get short notice anyway and so any redistribution should work on short notice, and that omitting unnecessary releases saves everybody time. If we started to release more often, we would in effect be asking every downstream developer and distributor to inspect every release and decide whether that release's changes are important and urgent enough for them to update.

If the problem is that ICU won't look at tzdata except just after an "official" tzdb release and that the ICU folks then take some time to do translations and that Apple won't use the new tzdb update until after ICU has done their translations, then that leisurely process needs to be streamlined regardless of tzdb's version numbering scheme. If this diagnosis is correct, I suggest that Apple work with ICU to have a more incremental process where ICU does not wait until an "official" tzdb release before starting work on translating changes. This should not involve any major technical change on ICU's side (they merely need to use version 2016j-38-g46c2bbf instead of version 2016j, say). ICU will have to track tzdb more closely, but that will be true no matter what version-numbering scheme is used. The main problem here is the delay in downstream translation, not in whether the current tzdb version is called '2016j-38-g46c2bbf' or '2017a'.

Suggest orgs should preemptively file bug reports at CLDR, ICU, and internally noting that time in America/PuntaArenas will change on 2019-05-11 and will be supported in a future release of tz, CLDR, ICU, products...and suggesting an alternative zone as a workaround. That's about all anyone can do for now, as it is unlikely that orgs will change their policies (does anyone seriously think that s/w orgs will deal with anything but frozen releases, even internally) nor will politicians (does anyone seriously thing that govs will ever give adequate notice of time changes, which will affect their own systems most of all). [As a subscriber to the BOFH attitude "lack of planning on your part does not constitute an emergency on mine", perhaps political change could best be accomplished by not jumping on last minute changes and allowing them to meander through all the normal downstream update processes to get into products. As the bureaucrats and politicians see their watches, phones, web sites, and systems showing the "wrong" times and eventually different times, it is unlikely but remotely possible a few of them could be enlightened. It's unfortunate that govs take such a dim view of using clue sticks on their political masters, except when applied by the populace en masse: see "Bastille". And maybe reporting and handling future bugs could be added as a logical extension to test driven development processes ;^>] -- Take care. Thanks, Brian Inglis, Calgary, Alberta, Canada

On 24/01/17 19:51, Deborah Goldsmith wrote:

The point is, many TZ clients (not just Apple, not just ICU) consider a change that takes effect in 3 1/2 months “urgent.” It is not just a matter of development cycles; it’s also a matter of release cycles.

There are some TZ clients who can turn a change around in a few days, and there are some that require much more lead time. Telling the latter that it’s their problem they have a different business model from the former is not productive.

I'm with one of the "turn a change around in a few days" distros but I have every sympathy with you Debbie. Sometimes even a few days isn't fast enough -- we've had some people demanding an update on the basis of a rumour before now and, of course, some countries are fond of changing the DST rules with next to no notice. RFC7808 (tzdist) hit the streets in March 2016 and I've been waiting with bated breath to see it actually implemented anywhere. I've turned an interesting shade of blue now, but I'm still hopeful[1]. Roll on tzdist ... jch [1] One of the authors of RFC7808, Cyrus Daboo is also from Apple so I'm hopeful that Apple will turn out something soonish, perhaps in Autumn? Fingers crossed.

It’s not just the TZ database itself. There’s also: 1. ICU metazone information (both Google and Apple use ICU) 2. Time zone geographical information (for automatic selection) 3. Localized names for time zones and/or cities within them (for manual selection) When just the behavior of existing zones is modified, then updating TZ and ICU is enough. When new zones are added (by splitting existing zones), there’s a lot more subsidiary information that needs updating. Thanks, Debbie

On Jan 25, 2017, at 2:36 AM, John Haxby <john.haxby@oracle.com> wrote:

On 24/01/17 19:51, Deborah Goldsmith wrote:

...

The point is, many TZ clients (not just Apple, not just ICU) consider a change that takes effect in 3 1/2 months “urgent.” It is not just a matter of development cycles; it’s also a matter of release cycles.

There are some TZ clients who can turn a change around in a few days, and there are some that require much more lead time. Telling the latter that it’s their problem they have a different business model from the former is not productive.

I'm with one of the "turn a change around in a few days" distros but I have every sympathy with you Debbie. Sometimes even a few days isn't fast enough -- we've had some people demanding an update on the basis of a rumour before now and, of course, some countries are fond of changing the DST rules with next to no notice.

RFC7808 (tzdist) hit the streets in March 2016 and I've been waiting with bated breath to see it actually implemented anywhere. I've turned an interesting shade of blue now, but I'm still hopeful[1].

Roll on tzdist ...

jch

[1] One of the authors of RFC7808, Cyrus Daboo is also from Apple so I'm hopeful that Apple will turn out something soonish, perhaps in Autumn? Fingers crossed.

On 25/01/17 16:14, Deborah Goldsmith wrote:

I would be very much in favor of a regular release schedule supplemented by urgent releases for immediate issues.

A release on the 15th of every month (for example; avoiding the beginning and end) would greatly simplify things for our support org: they'd know when a release was coming and could tell customers exactly when it was due.

Debbie

...

On Jan 25, 2017, at 4:47 AM, Tony Finch <dot@dotat.at> wrote:

I wonder if it would make sense for the tz database to have a regular release schedule, e.g. monthly. How often would it be necessary to release more urgently?

Tony. -- f.anthony.n.finch <dot@dotat.at> http://dotat.at/ - I xn--zr8h punycode Fitzroy, Sole: Southerly, veering westerly later in west, 5 to 7, increasing gale 8 or severe gale 9 at times. Rough or very rough, occasionally high. Occasional rain. Good, occasionally poor.

On Wed, 25 Jan 2017, Deborah Goldsmith wrote:

I would be very much in favor of a regular release schedule supplemented by urgent releases for immediate issues.

It is what we started doing for PHP as well. Very regular releases, with exceptions for "security releases". It's been a great success. Everybody around the ecosystem knows when releases are coming, and it is easy to communicate that if you want your change/fix/feature in a new release, it needs to be done by x date. I think this would be hugely beneficial for the tz project too - it can also be used as a stick to communicate to organisations that *change* the rules, that this is when their computers are getting updated. cheers, Derick

...

On Jan 25, 2017, at 4:47 AM, Tony Finch <dot@dotat.at> wrote:

I wonder if it would make sense for the tz database to have a regular release schedule, e.g. monthly. How often would it be necessary to release more urgently?

Tony. -- f.anthony.n.finch <dot@dotat.at> http://dotat.at/ - I xn--zr8h punycode Fitzroy, Sole: Southerly, veering westerly later in west, 5 to 7, increasing gale 8 or severe gale 9 at times. Rough or very rough, occasionally high. Occasional rain. Good, occasionally poor.

-- https://derickrethans.nl | https://xdebug.org | https://dram.io Like Xdebug? Consider a donation: https://xdebug.org/donate.php twitter: @derickr and @xdebug