The code was taking a rule like May 31 24:00 (Asia/Jerusalem) and moving May 31 to Jun 1 because of the 24:00, then trying to set it to the 31st. I've hacked the code to avoid changing the day until later in the logic, but ultimately the code is quite brittle because of the complexity of the input format. I would note that this code has existed unchanged for 17 years - the seemingly innocuous change from Jun 1 00:00 to May 31 24:00 caused the issue (and similar changes). A reminder that there is no such thing as a completely innocuous change. Stephen On Sun, 27 Dec 2020 at 18:54, Paul Eggert <eggert@cs.ucla.edu> wrote:
On 12/27/20 1:20 AM, Stephen Colebourne wrote:
https://github.com/JodaOrg/joda-time/runs/1607329443?check_suite_focus=true#...
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.