[tz] Politics of TZ changes

[walter harms]

Am 20.05.2014 06:17, schrieb Brian Inglis:
> On 2014-05-19 08:18, Paul_Koning at dell.com wrote:
> 
>> On May 18, 2014, at 10:35 AM, Arthur David Olson
>> <arthurdavidolson at gmail.com> wrote:
> 
>>> Fact finding is part of encouraging governments to do the right
>>> thing about changing daylight saving.
>>> This week Paul Eggert noted how changes propagated to a system
>>> within a day of being released.
>>> That's the best case. What's the worst case?
> 
>> For embedded systems with long QA cycles, it could easily be a year.


This why we run our systems on UTC time. Only when user interaction
is requiered we use localtime.

re,
 wh

> 
> For enterprise systems, likely to be quarterly desktop core system
> patching, and quarterly to annual server core system patching.
> 
>>> And: what's best practice?
>> The most recent change to US DST was the Energy Policy Act of 2005;
>> it was signed into law on 2005-08-08; the first change resulting
>> from the law was 2007-03-11, meaning there was more than 18 months
>> of advance notice. Has there been a longer lead time?
>> Has any government gotten closer to a zero lead time than Egypt?
> 
> For 2007 North American change, some Canadian provinces did not
> enact a law until pretty close to the initial cutover.
> 
>> I distinctly remember some years ago a change that had negative lead
>> time.
>> Another with lead time measured in minutes.
> 
> Anyone with access to a tz repository having historical commit
> timestamps could compare those against the zone/rule change
> date/times in patches to come up with min/max lead times.