Am 20.05.2014 06:17, schrieb Brian Inglis:
On 2014-05-19 08:18, Paul_Koning@dell.com wrote:
On May 18, 2014, at 10:35 AM, Arthur David Olson <arthurdavidolson@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.