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.
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. -- Take care. Thanks, Brian Inglis