Hi, Just my two cents. Even though I would love the idea of a version that would correctly predict the future DST transitions in Fiji, I think I would vote for the "non-DST is default"-rule, and have DST transitions as "this year only". In theory, it sounds OK, to only have to apply a new patch when there is a deviation from the prediction. But in practice it creates more work the years where there is an exception. Especially when the suggested DST transition is later than the prediction (like this year). The reason it creates more work is the perception here, that DST is decided on a yearly basis. There is no understanding that some foreign body has predicted when DST will happen. We can try to educate decision makers on this, but I don't have high hopes, and also decision makers change. I even have problems explaining to my own management why there is a problem with DST in Fiji. Maybe my pedagogical skills are not up to scratch. Just an example for this year. The way Fiji Government see it, they gave 13 days notice. 13 days is less than the promised 2 months, but it should be enough for us to at least get a temporary patch in, and hopefully an official tzdata version. But what happen this year, of course, is that in reality it's only 6 days notice, since the predicted patch in place assumes Oct 26, only 6 days away form Oct 20. To make things even worse, it looks like we have installed some new Java installations since last years "silly season". These Java versions predicted DST transition on Oct 19 (probably a prediction from around 2011-12), so we are already behind. Admittedly this should have been caught by our internal processes and procedures, so this is entirely our fault. In short, until Fiji Government states that they will follow some kind of rule for the future, I think DST rules year-by-year is the best approach (unfortunately), since it best reflects what is the actual situation in Fiji at the moment. Cheers, /Ken On 21/10/2014 6:22 AM, Tim Parenti wrote:
It's not been our goal to reflect official policy so much as to reflect actual practice. I'm of two minds about which route we should take in this instance. To me, it boils down to which is likely to be less work for future maintenance, and on that, I'd bet your guess is as good as mine. ;)
If we decide instead not to predict DST moving forward, an alternative proposed patch is attached. (This is either/or w.r.t. my earlier patch, not cumulative.)
-- Tim Parenti
On 20 Oct 2014 14:02, Paul_Koning@Dell.com wrote:
On Oct 20, 2014, at 1:17 PM, Tim Parenti <tim@timtimeonline.com> wrote:
Attached is a proposed patch.
My patch assumes that this year's November start date is a one-time departure from the recent norm of Oct Sun>=21, and that DST will continue in 2015/2016 and beyond according to the pattern used between 2010 and 2014. (For now, it seems to me that we're more likely to be closer to correct by assuming some DST in the future than by assuming none.)
But given the apparent policy statement that the default is “no DST”, I think it would be better for our rules to say so. In other words, make the current rule a once-only rule, and from then forward no DST. Comments explaining why would be useful, given that a “no DST” default isn’t the obvious answer if you look at past practice. Still, it’s one thing to infer a future rule from past behavior in the absence of any other data; it’s rather a different matter to continue doing so after we’ve been told that this isn’t the right way to look at things.
paul