[tz] Magallanes region from Chile will keep DST all year round

Brian Inglis Brian.Inglis at SystematicSw.ab.ca
Tue Jan 24 20:09:41 UTC 2017

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

More information about the tz mailing list