Re: [tz] Fiji DST for 2012-2013 announced
(oops, sent it directly instead of to the list at first) On Sun, Sep 2, 2012, at 00:12, lord.buddha@gmail.com wrote:
I now also wonder if the presumption of a pattern might cause conflicts with other sources. IATA / Microsoft etc.
I think Microsoft's practice has generally been to have extrapolated rules, hope for the best, and publish a hotfix if it doesn't match. My (unpatched) Windows 7 machine extends the 2010 rule [Fourth Sunday October to Last Sunday March] on to infinity. They have published at least two updates since then that I've been able to find that tweak the rules, and I haven't verified firsthand but have no particular reason to doubt they similarly extend the then-latest rules [Fourth Sunday January to First Sunday March, based on update description text] indefinitely, and expect to publish further hotfixes. -- Random832
On 2012-09-05 21:19, random832@fastmail.us wrote:
(oops, sent it directly instead of to the list at first)
On Sun, Sep 2, 2012, at 00:12, lord.buddha@gmail.com wrote:
I now also wonder if the presumption of a pattern might cause conflicts with other sources. IATA / Microsoft etc.
I think Microsoft's practice has generally been to have extrapolated rules, hope for the best, and publish a hotfix if it doesn't match. My (unpatched) Windows 7 machine extends the 2010 rule [Fourth Sunday October to Last Sunday March] on to infinity.
On my up-to-date Windows 7 system, the recurring rule for Fiji runs from the Fourth Sunday of October to the Fourth Sunday of January: "TZI"=hex:30,fd,ff,ff,00,00,00,00,c4,ff,ff,ff,00,00,01,00,00,00,04,00,03,00,00,\ 00,00,00,00,00,00,00,0a,00,00,00,04,00,02,00,00,00,00,00,00,00 (see <http://msdn.microsoft.com/en-us/library/ms725481.aspx> for interpretation). It currently has dynamic DST rules for years 2008 to 2013, but the information for the 2012-2013 DST period is currently incorrect. They have DST beginning on the 4th Sunday of October 2012 (2012-10-28) and finishing on the 1st Sunday of March 2013 (2013-03-03): "2012"=hex:30,fd,ff,ff,00,00,00,00,c4,ff,ff,ff,00,00,01,00,00,00,04,00,03,00,\ 00,00,00,00,00,00,00,00,0a,00,00,00,04,00,02,00,00,00,00,00,00,00 "2013"=hex:30,fd,ff,ff,00,00,00,00,c4,ff,ff,ff,00,00,03,00,00,00,01,00,03,00,\ 00,00,00,00,00,00,00,00,0a,00,00,00,04,00,02,00,00,00,00,00,00,00 Presumably they'll get round to fixing it on their next round of time zone updates.
They have published at least two updates since then that I've been able to find that tweak the rules, and I haven't verified firsthand but have no particular reason to doubt they similarly extend the then-latest rules [Fourth Sunday January to First Sunday March, based on update description text] indefinitely, and expect to publish further hotfixes.
Microsoft's time zone information cannot encode penultimate Sundays, so if that's the rule, they'll have to use a "dynamic" DST rule each year, or change the way they store and interpret time zone information (which would have knock-on effects for applications that store and retrieve time zone information). http://msdn.microsoft.com/en-us/library/ms725481.aspx They don't store much historic information and only allow two transitions per year, so the temporary suspensions of DST by various also throw a spanner in the works, requiring hot-fixes to be applied at certain times of the year in those countries. -- -=( Ian Abbott @ MEV Ltd. E-mail: <abbotti@mev.co.uk> )=- -=( Tel: +44 (0)161 477 1898 FAX: +44 (0)161 718 3587 )=-
On 07/09/12 12:16, Ian Abbott wrote:
Microsoft's time zone information cannot encode penultimate Sundays, [...]
And of course, a "POSIX-style" TZ environment variable string can't encode it either! Does zic omit the recurring rule string from the end of the version 2 tzfile in this case? -- -=( Ian Abbott @ MEV Ltd. E-mail: <abbotti@mev.co.uk> )=- -=( Tel: +44 (0)161 477 1898 FAX: +44 (0)161 718 3587 )=-
participants (2)
-
Ian Abbott -
random832ļ¼ fastmail.us