[tz] Politics of TZ changes
wharms at bfs.de
Tue May 20 09:22:05 UTC 2014
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.
> 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
>> 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.
More information about the tz