[tz] Fiji DST Oct 26

[Ken Rylander]

Hi,

Excellent point, Deborah and Andy. I hereby change my vote to 
predictions for the future, and creating exceptions, whenever the 
prediction is wrong. And maybe, as Tim said, a late date. At least until 
we see a more stable pattern.

I see your email addresses, and understand where you're coming from. I 
am working for a mobile operator, and completely forgot the big problems 
we have with tz files in handset OS's (iOS, Android etc.). As you said, 
the lead-time here is a lot longer. And not every user will update their 
OS to the latest version, even if it's available. A qualified guess is 
definitely better than no DST data at all.

For my UNIX servers and Java applications, I can control what timezone 
files to use. But regarding handset OS's, there is currently no official 
way of updating the tz data. Hopefully that will change in the future. 
After all, they are called smartphones, so there should be a way to 
"tell them" about late changes to timezone information.

Cheers,
/Ken


On 21/10/2014 10:51 AM, Deborah Goldsmith wrote:
> Unfortunately, some tz clients have much longer lead times than 13 days. Such clients may not be able to get a release out soon enough to have the correct transition date. Some customers of those clients may not get an update for months.
>
> Given that, it is better to have a default which correctly predicts whether DST will happen at all. Getting the transition date right is a secondary (but still highly desirable!) consideration. If we have the default as no DST and there is DST, then customer’s time stamps might be wrong for weeks or months, until an update can be released. If the transition date is wrong but there is still DST, then their time stamps are wrong for a few days, maybe a week or two (the difference between the predicted and the actual transition date). The latter is far preferable for any tz client whose deployment cycle takes weeks or months.
>
> So, I’d rather see IANA continue with the current approach of predicting DST.
>
> Thanks,
> Deborah
>
>> On Oct 20, 2014, at 3:29 PM, Ken Rylander <ken at lajbans.com.au> wrote:
>>
>> 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
>>>>