[tz] Fiji DST Oct 26

[""]

Just commenting...

13 Days prior is not the biggest problem.   Airlines sell tickets up to 360
days in advance of travel...

IATA,* I believe*, did not have DST for Fiji this year until after this
announcement which meant that flight durations calculated from IATA
published schedules and IANA published TZ data would been incorrect for
flights on/after the 26th October.

Yes, probably the pattern would have held this year had it not been for the
recent elections.



On 21 October 2014 14:03, Ken Rylander <ken at lajbans.com.au> wrote:

> 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
>>>>>
>>>>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mm.icann.org/pipermail/tz/attachments/20141021/a668050f/attachment-0001.html>