A bug indeed. Our clue is the zic.c comment "Mark which rules to do in the current year" which zic is hellbent on doing even if they're duplicates. A start on a fix is the (tab munged) change below; it flags the case reported by Jon Skeet, and does not produce any false reports of errors for the files in the time zone package. It should pick up glitches other than exactly duplicated rules. An unmunged version of the patch is attached. --ado 1.1 2959 lines 1.3 2966 lines *** /tmp/,azic.c 2015-07-19 14:29:15.286318600 -0400 --- /tmp/,bzic.c 2015-07-19 14:29:15.391324600 -0400 *************** *** 2372,2377 **** --- 2372,2384 ---- jtime == max_time) continue; jtime = tadd(jtime, -offset); + if (jtime == ktime) { + eats(zp->z_filename, zp->z_linenum, rp->r_filename, rp->r_linenum); + warning(_("two rules for same instant")); + rp = &zp->z_rules[k]; + eats(zp->z_filename, zp->z_linenum, rp->r_filename, rp->r_linenum); + error(_("two rules for same instant")); + } if (k < 0 || jtime < ktime) { k = j; ktime = jtime; On Sun, Jul 19, 2015 at 1:36 PM, Paul Eggert <eggert@cs.ucla.edu> wrote:
Jon Skeet wrote:
if anyone can think of any good justification why an implementation*should* behave like zic in this case, I'd be really interested to hear it.
I think you've identified a bug in zic. Perhaps Arthur can chime in?