[tz] Joda-Time compiler broken again

[Paul Eggert]

On 12/27/20 1:20 AM, Stephen Colebourne wrote:
> https://github.com/JodaOrg/joda-time/runs/1607329443?check_suite_focus=true#step:11:693

Could you arrange for a buildbot to run Joda-Time on the tzdb 
development repository on GitHub too? That would help catch problems 
like this earlier.

> Presumably, some rule now contains a 31 in a 30 day month now?
I just ran 'git diff 2020d..2020e' and saw that "31"s were introduced 
only for Mar, May, Jul, Aug, Oct, Dec, so I don't see such a calendar 
error introduced in tz2020e.

It's hard to tell from Joda-Time's log file what the problem is, as it 
doesn't report the tz input file name or line number. The only useful 
info the exception handler gives is "Value 31 for dayOfMonth must be in 
the range [1,30]". However, I did see some "31"s in 2020e that were not 
in 2020d, namely, lines that I've manually marked with "*" in the 
following listing generated by "grep -n -E 
'[^#].*[[:space:]]31[[:space:]]+24' $(git ls-files) | sed -E 
's/[[:space:]]+/ /g; s/^/  /'":

   africa:355:Rule Egypt 2014 only - Jul 31 24:00 1:00 S
  *africa:533: 2:30 - +0230 1936 Dec 31 24:00
  *africa:534: 2:45 - +0245 1942 Jul 31 24:00
   asia:232:Rule Dhaka 2009 only - Dec 31 24:00 0 -
   asia:412:Rule Shang 1947 only - Oct 31 24:00 0 S
  *asia:1870:Rule Zion 1940 only - May 31 24:00u 1:00 D
  *asia:1873:Rule Zion 1942 1946 - Oct 31 24:00u 0 S
  *asia:1874:Rule Zion 1943 1944 - Mar 31 24:00u 1:00 D
  *asia:1877:Rule Zion 1948 only - Aug 31 24:00u 1:00 D
  *asia:1878:Rule Zion 1948 1949 - Oct 31 24:00u 0 S
  *asia:1882:Rule Zion 1951 only - Mar 31 24:00u 1:00 D
  *asia:1918:Rule Zion 1985 only - Aug 31 24:00 0 S
  *asia:1964:Rule Zion 1991 only - Aug 31 24:00 0 S
   europe:1756:Rule Italy 1917 only - Mar 31 24:00 1:00 S
  *northamerica:2966:Rule Bahamas 1944 only - Dec 31 24:00 0 S

Given that the last Joda-Time output before it crashed was "Fixed 
negative save values for rule 'Namibia'", one possibility is that 
Joda-Time mishandles 24:00 at month or year end in continuation lines 
like africa:533. Less likely possibilities include mishandling 24:00u at 
month end in Rule lines like asia:1870, or mishandling Dec 31 24:00 in 
the western hemisphere in Rule lines like northamerica:2966.

 From the "Fixed negative save values" diagnostic it appears that 
Joda-Time is operating on main data not rearguard data, so this is not 
an issue that can be fixed by futzing with ziguard.awk. Not that I'm a 
fan of ziguard.awk - it's a hack and the latest problem with Apple 
suggests that it might now be more trouble than it's worth.