I wouldn’t call no DST, when DST has been in place for a number of years, “status quo”. It might be what the people making the decision thought of as the default answer, but if so it doesn’t appear they ever communicated that point of view. Otherwise the TZ rules would have reflected it. As it is, the database reflects the best guess of outside observers. No one is forcing anything, but the authorities may want to consider the fact that global databases can’t be updated overnight. So while it would be convenient to be able to make a decision one day ahead of time, it isn’t actually practical to do so. If you want the rest of the world to be able to deal with the rules, they need to be communicated with some lead time. I don’t know what the TZ maintainers think is a reasonable minimum; given additional processing in OS patch procedures etc., it really is desirable to get these decisions finalized at least a couple of months ahead of time. As I’ve pointed out, some of us build systems where the lead times are closer to a year. paul On Oct 14, 2014, at 6:41 PM, Ken Rylander <ken@lajbans.com.au> wrote:

Hi Brian,

We have asked the Ministry multiple times, but no decision has been made.

I guess they see it as if the TZDB is "forcing" them to have DST this year. The Fiji Government have had DST the last couple of years, but never said it was permanent. The decision was always made each year. Never predicting anything about the future. So to them, not making any decision about DST in 2014, would mean status quo, i.e. no DST 2014.

Cheers, /Ken

On 14/10/2014 9:12 PM, Brian Inglis wrote:

...

On 2014-10-14 02:04, Ken Rylander wrote:

...

There might be an issue with the Fiji DST (Pacific/Fiji), predicted to happen on Oct 26, at 3am. It looks like the Fiji government haven't yet decided on whether to have DST this year, or not. And in that case, on what date it will start. There was recently elections here, and it seems like the Fiji government haven't prioritised any decisions around DST. Taking this into consideration, and also the fact that this future, predicted date was introduced by the TZDB, would it be possible to get a tzdata version, where the DST for 2014 is removed?

How about asking your Ministry of Information to make an announcement about whether or not Fiji will start DST on Oct 26 at 03.00, as the rest of the world expects it to? If not, times on some airline tickets may need adjusted, and all computers updated, as soon as changes can be released by tz and IATA. You government website provides many contact options for the Ministry.

Paul_Koning@dell.com wrote:

I don’t know what the TZ maintainers think is a reasonable minimum

We can typically turn it around in a day or two for the tz database itself, but as you say it can take quite some time for this info to filter through all the channels, channels that we have no control over. As Fiji has observed DST for five years running, it was plausible to guess DST this year too. However, it appears that Ken is guessing Fiji won't have DST this year, and he's closer to the ground and more likely to guess correctly than the rest of us, so I'm inclined to apply the attached proposed patch and publish a new tz version in the next week or so. We need a new version anyway for Belarus's time zone abbreviation change October 26. Ken, please let us know of any further info you get about this. That way, if we get better information before next week we can revert this patch before publishing the next tz release. Thanks.

Tim Parenti wrote:

attached is a small patch to NEWS for more consistency with recent release notes

Thanks, I applied that to the experimental github version.

Hi Paul, Agree completely. And believe me, no-one would be happier than me, if they decide to go with DST after all. Because that would mean that I don't have to patch around 100 servers (OS, like Windows, Solaris, Linux + all Java Homes), and roll back the DST patch for last year. And all to be done within 10 days. The corporation I represent keep lobbying to get the information through to the decision makers, and also trying to get other companies, like Fiji Airways (because, as Tim pointed out, airlines would have a special interest in this) to do the same. But no luck yet. The latest information we received said that the government would always give 2 months notice before DST. I am not sure they have, since DST was re-introduced in 2009. But leaving that aside, their reasoning would be that status quo, means no DST. So even though the TZDB prediction was completely logical when put in place last year, as it stands now, a best guess for an outside observer (as myself), would be that there will be no DST this year. Or possibly, that there will be DST, but that it will start later in the year. Cheers, /Ken On 15/10/2014 12:43 PM, Paul_Koning@Dell.com wrote:

I wouldn’t call no DST, when DST has been in place for a number of years, “status quo”. It might be what the people making the decision thought of as the default answer, but if so it doesn’t appear they ever communicated that point of view. Otherwise the TZ rules would have reflected it. As it is, the database reflects the best guess of outside observers.

No one is forcing anything, but the authorities may want to consider the fact that global databases can’t be updated overnight. So while it would be convenient to be able to make a decision one day ahead of time, it isn’t actually practical to do so. If you want the rest of the world to be able to deal with the rules, they need to be communicated with some lead time. I don’t know what the TZ maintainers think is a reasonable minimum; given additional processing in OS patch procedures etc., it really is desirable to get these decisions finalized at least a couple of months ahead of time.

As I’ve pointed out, some of us build systems where the lead times are closer to a year.

paul

On Oct 14, 2014, at 6:41 PM, Ken Rylander <ken@lajbans.com.au> wrote:

...

Hi Brian,

We have asked the Ministry multiple times, but no decision has been made.

I guess they see it as if the TZDB is "forcing" them to have DST this year. The Fiji Government have had DST the last couple of years, but never said it was permanent. The decision was always made each year. Never predicting anything about the future. So to them, not making any decision about DST in 2014, would mean status quo, i.e. no DST 2014.

Cheers, /Ken

On 14/10/2014 9:12 PM, Brian Inglis wrote:

...

On 2014-10-14 02:04, Ken Rylander wrote:

...

There might be an issue with the Fiji DST (Pacific/Fiji), predicted to happen on Oct 26, at 3am. It looks like the Fiji government haven't yet decided on whether to have DST this year, or not. And in that case, on what date it will start. There was recently elections here, and it seems like the Fiji government haven't prioritised any decisions around DST. Taking this into consideration, and also the fact that this future, predicted date was introduced by the TZDB, would it be possible to get a tzdata version, where the DST for 2014 is removed? How about asking your Ministry of Information to make an announcement about whether or not Fiji will start DST on Oct 26 at 03.00, as the rest of the world expects it to? If not, times on some airline tickets may need adjusted, and all computers updated, as soon as changes can be released by tz and IATA. You government website provides many contact options for the Ministry.

Hi, ...and keeping with the strict policy of giving 2 months notice, Fiji Government just released the following statement saying that DST will start Nov 2 this year. 13 days notice, by my calculation. http://www.fiji.gov.fj/Media-Center/Press-Releases/DAYLIGHT-SAVING-STARTS-ON... Cheers, /Ken Ken Rylander | Solution Development and BI Manager - Digicel Pacific | Digicel (Fiji) Ltd | P.O.Box 13811, Suva, Fiji | Ground Floor, Kadavu House, Victoria Parade, Suva, Fiji | Mobile (679) 701 5353 | Fax (679) 331 0201 | ken.rylander@digicelgroup.com | www.digicelpacific.com -----Original Message----- From: Paul Eggert [mailto:eggert@cs.ucla.edu] Sent: Wednesday, 15 October 2014 5:34 PM To: ken@lajbans.com.au; Paul_Koning@Dell.com Cc: tz@iana.org Subject: Re: [tz] Fiji DST Oct 26 Ken Rylander wrote:

The latest information we received said that the government would always give 2 months notice before DST.

Two months notice would be good. It would mean that Fiji won't start DST before December 14.

I am not sure they have, since DST was re-introduced in 2009.

Here are the notices of the past four years or so: 2010-10-13, 9 days notice: http://www.fiji.gov.fj/Media-Center/Press-Releases/Daylight-savings-on-horiz... 2011-02-25, 9 days notice: http://www.fiji.gov.fj/Media-Center/Press-Releases/Daylight-savings-ends-on-... 2011-10-03, 20 days notice: http://www.fiji.gov.fj/Media-Center/Press-Releases/Daylight-saving-starts-Oc... 2012-08-27, 55 days notice: http://www.fiji.gov.fj/Media-Center/Press-Releases/DAYLIGHT-SAVING-STARTS-ON... 2013-08-30, 59 days notice: http://www.fiji.gov.fj/Media-Center/Press-Releases/DAYLIGHT-SAVING-STARTS-ON... Although they've done better since 2012, it's a bit of an exaggeration to say that they always give two months notice.

On Mon, Oct 20, 2014, at 04:25, Ken Rylander wrote:

Hi,

...and keeping with the strict policy of giving 2 months notice, Fiji Government just released the following statement saying that DST will start Nov 2 this year. 13 days notice, by my calculation.

Well, at least they can't hide behind "you should have just assumed by default that there would be no DST unless there was an announcement" when people complain about the short notice, as was being speculated last week.

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

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

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@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@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

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.

I don't see why durations would change. Presumably the airlines will just run the flights on their old timings in UTC terms, meaning they arrive and depart Fiji one hour later on the clocks, but at the same real time. Yes, they have to tell their passengers, but they do that for all kinds of reasons anyway. (I'm still annoyed that Cathay Pacific have a daily flight - that is, scheduled every day until at least next May - that cancelled *on 10th November only*. Guess which date I was booked to take that flight.) -- Clive D.W. Feather | If you lie to the compiler, Email: clive@davros.org | it will get its revenge. Web: http://www.davros.org | - Henry Spencer Mobile: +44 7973 377646

On 21/10/14 02:03, Ken Rylander wrote:

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.

Which is the object of the tzdist working group, but I'd like to see a little more consideration given to how a short notice change is flagged. That a meeting was scheduled perhaps 12 months before for next week and it may now happen an hour adrift is easy to miss if one has the original time in your head? ;) Not a problem for tz or tzdist but since we have the information that a change is required ... -- Lester Caine - G8HFL ----------------------------- Contact - http://lsces.co.uk/wiki/?page=contact L.S.Caine Electronic Services - http://lsces.co.uk EnquirySolve - http://enquirysolve.com/ Model Engineers Digital Workshop - http://medw.co.uk Rainbow Digital Media - http://rainbowdigitalmedia.co.uk

On 21 October 2014 01:54, Clive D.W. Feather <clive@davros.org> wrote:

Deborah Goldsmith said:

...

[...] The latter is far preferable for any tz client whose deployment cycle takes weeks or months.

Actually, I'm not sure that's true.

If we don't have any change in there and one happens, timestamps are wrong for months but it should be obvious to people that they are wrong and need correcting.

As Deborah alluded to, I think the key is the whether the deployment cycle is long or short. For many consumer devices these days (e.g., phones, embedded systems), there are enough layers between tz and the end user that short-notice changes like this simply won't make it to them in time. In that case, it's better to assume something slightly incorrect than to assume no changes, since the end user may not be able to update the data themselves, or may otherwise be resigned to employ kludgy workarounds. If the end user doesn't have a say in the matter, to simplify their lives, it's better to have them experience mostly correct data than knowingly false data. This is in contrast to people administering more complex systems (e.g., servers, networks), who should presumably know enough about what they're doing to be able to proactively (or at least reactively) seek solutions. Obviously, it is a goal of the tzdist working group to reduce this number of layers and/or the time it takes changes to propagate through them, perhaps to a point where not assuming changes long-term becomes the more reasonable option. I don't think we're there yet, though, so I approve of Paul's conclusion. -- Tim Parenti

Date: Mon, 20 Oct 2014 18:02:47 +0000 From: <Paul_Koning@dell.com> Message-ID: <70BBB1E8-CAE1-4708-A625-B06F1586C5C9@dell.com> | But given the apparent policy statement that the default is “no DST”, ... I agree with Tim - what's more, for the past few years, that policy (which was always in place) would have required last minute releases to enter the date for Fiji, which our guess (which happened to be correct) allowed to be avoided. This year (most likely because of the change of Govt, I guess) we weren't that lucky, and now it is harder to form a reliable guess as to what the likely (de facto) rule will be into the future - but it seems very very likely, given that they did not decide to abandon summer time this year, that some dates will be needed, so while it is entirely possible that next year will need another last minute fix, if we pick a date now, we at least have a chance of being right. If we don't (if we assume no summer time) then it seems much less likely that our guess will be correct. kre ps: also note; that because of the old guess (not having a release with no summer time in Fiji), anyone who doesn't get the update in time this year will have just a week of incorrect times - if we had guessed "no summer time" then people would have continuously incorrect conversions, until they updated. Once again, having guessed a date is a clear win. We only lose if they eventually (without reasonable warning) cancel summer time completely.

There's a third solution (attached): Assume the later start date moving forward. This gives us the best of both worlds — We assume DST (which is likely), but we have more lead-time available to us in case future announcements differ. -- Tim Parenti On 20 Oct 2014 19:33, Andy Heninger wrote:

I would also prefer that the tz database continue with making a best guess at future transitions.

Even when the guess is off somewhat, as it is this year, the net result is better for the all-too-many systems that don't get fast updates. Having time wrong for a week is less bad than having the time wrong for a month or more.

-- Andy

On Oct 14, 2014, at 11:11 PM, Ken Rylander <ken@lajbans.com.au> wrote:

... The latest information we received said that the government would always give 2 months notice before DST. I am not sure they have, since DST was re-introduced in 2009. But leaving that aside, their reasoning would be that status quo, means no DST.

So even though the TZDB prediction was completely logical when put in place last year, as it stands now, a best guess for an outside observer (as myself), would be that there will be no DST this year. Or possibly, that there will be DST, but that it will start later in the year.

Yes, that makes sense. In the past, we had no information about the way the authorities viewed this matter. Now, based on your data, we do — namely that there will be no DST in any particular year unless there is an explicit decision that there will be. In other words, the old assumption (same rule from one year to the next unless superseded) is now known not to be the right one, and the right one instead is “Fiji DST rules should all be of the form ‘this year only’”. That’s real data and something we can handle. It would be a good idea to communicate that to the authorities (once the change has indeed been made) so they know we did this in response to their feedback. And it will also help make the point that it’s now up to them to communicate if they do intend to have DST, and to try to do so with a useful lead time. Your own experience can help explain why the lead time is important. paul