[tz] Fiji DST Oct 26
Ken Rylander
ken at lajbans.com.au
Mon Oct 20 22:29:35 UTC 2014
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 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