[tz] Fiji DST Oct 26

Ken Rylander ken at lajbans.com.au
Mon Oct 20 22:29:35 UTC 2014


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 

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.


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 at Dell.com wrote:
>> On Oct 20, 2014, at 1:17 PM, Tim Parenti <tim at 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

More information about the tz mailing list