2019b database rule for Zion causes compilation failure

[Pamoho]

G'day all,

We've been trying to install the 2019b database with v1.8.2018c of Alex's excellent toolset, but TZcompile just kept shutting down. Eventually we tracked the root of the problem to the TzStrToDay function in Tzcompile\TZSchema.pas, which objects to the "Fri<=1" in the Asia file.

Doing a BCompare on "Asia" for 2019a and 2019b shows this is new code. There do not seem to be any other "Day<=nn" tests in the IANA source.

As a workaround we've set the test to "1" for now. Any suggestions on best way to fix the code? Is "Day<=nn" going to become a "thing"? Do we need to enhance TzStrToDay?

Cheers, Paul

TZcompile.log

[pavkam]

Morning,

I haven't touched that code for so long I can't even remember the rule format. This <= seems weird though. If it the last Friday of the previous month or first Friday of current one?

Alex.

[pavkam]

You mind making a pull request with the updated files if you applied the fix manually? Would be nice to update the TZDB to the latest DB.

[Pamoho]

Thanks Alex. I'll give this some thought. A little bit of investigation tonight suggests it is complex.

The actual DST rule is "double-barrelled" in that since 2005 DST in Israel starts on the Friday immediately before the Last Sunday in March.

Simple to say, but I suspect it is nearly impossible to translate into a TZDB Rule. So before I start playing with your code, I'll build some models, and make sure "Fri<=1" can be made to generate the right dates :-)

Cheers, Paul

[pavkam]

Hey Paul,

I have taken a few hours Today to make TZCompile work on FPC/Linux as that is my only environment at the moment.

I have also added a script that refreshes all the data automatically and rebuilds everything.

At this stage I have identified the new rule type and added support for it in both TZCompile and the library itself.

I would appreciated it if you could give it a look (see the latest master) as I am not capable of making good testing yet.

Alex.

[Pamoho]

G'day Alex,

Lucky today was cold and wet! I found some time to test out your latest. Good news and bad news (for someone else).

The code changes you made seem to handle the "strange" new rule ("Fri<=1") correctly.

Unfortunately, I don't think the new rule itself is correct! I relied on Wikipedia for 16 years of data. Because of the two-part rule that applies since 2005 (the Friday immediately before the last Sunday in March) five of the 16 years yield the wrong date for the start of DST.

I'll see if I can get this analysis through to the folk maintaining the IANA DB.

It doesn't cause us any problems (now that we can compile the TZdb **) but it may be an issue for other people needing accurate Israeli time data.

I attach a PDF that shows the details of my testing.

Cheers, Paul

** We do have a problem with compiling, but I'll raise that separately when time permits. PR01503.pdf

[pavkam]

Thanks for the effort Paul, I took advantage of the rain in Dublin as well!

When you get the chance to let me know what fails to compile in Delphi Rio please add a comment.

In the mean time I will try to set up a VM with community edition of Delphi and see if I can get to compile myself.

Cheers, Alex.

[Pamoho]

G'day Alex,

The "Fri<=1" rule is AOK with Delphi [Rio and Tokyo both :-) ]. No action required on your side there.

I woke up in the wee small hours with the "answer" to the rule not working for 33% of years, and this morning modelled it in Excel. Change the month to March (from April) and the rule to "Fri<=29". Works every time. And I thought it would be impossible(!)

I'll change the IANA source and rerun TZcompile etc. and let you know the results later.

Separate issue to be raised on the other TZcompile failure.

Cheers, Paul

[pavkam]

Hi Paul,

Thanks a mil for the work. Can we close this one as it seems the issue is now on IANA side?

Alex.

[Pamoho]

Happy to close :-)