<div dir="ltr">I'd be perfectly happy with declaring them obsolete, but I may not have the experience of others in terms of when they're useful. I wouldn't want to urge the removal of something that turns out to be crucial - although as you say, the feature doesn't work everywhere anyway.<div><br></div><div>For finite rules, the years in which they're valid can easily be expanded (possibly at the cost of readability).</div><div><br></div><div>Looking back a bit further, back in the <i>early</i> 90s the Adelaide zone ended up with rules like this:</div><div><br></div><div><div>Rule<span class="" style="white-space:pre"> </span>AS<span class="" style="white-space:pre"> </span>1987<span class="" style="white-space:pre"> </span>max<span class="" style="white-space:pre"> </span>-<span class="" style="white-space:pre"> </span>Oct<span class="" style="white-space:pre"> </span>lastSun<span class="" style="white-space:pre"> </span>2:00<span class="" style="white-space:pre"> </span>1:00<span class="" style="white-space:pre"> </span>-</div><div>Rule<span class="" style="white-space:pre"> </span>AS<span class="" style="white-space:pre"> </span>1990<span class="" style="white-space:pre"> </span>max<span class="" style="white-space:pre"> </span>even<span class="" style="white-space:pre"> </span>Mar<span class="" style="white-space:pre"> </span>Sun>=22<span class="" style="white-space:pre"> </span>3:00<span class="" style="white-space:pre"> </span>0<span class="" style="white-space:pre"> </span>-<br></div><div>Rule<span class="" style="white-space:pre"> </span>AS<span class="" style="white-space:pre"> </span>1990<span class="" style="white-space:pre"> </span>max<span class="" style="white-space:pre"> </span>odd<span class="" style="white-space:pre"> </span>Mar<span class="" style="white-space:pre"> </span>Sun>=1<span class="" style="white-space:pre"> </span>3:00<span class="" style="white-space:pre"> </span>0<span class="" style="white-space:pre"> </span>-</div></div><div><br></div><div>From a purely selfish point of view, that's a nightmare for Noda Time - both in terms of having infinite year-type-based rules, and having 3 infinite rules rather than 2 to start with. We may well be best off hoping that no governments come up with such annoying rules in the future, but it's probably worth thinking about.</div><div><br></div><div>(I would have raised this case before, but I hadn't spotted it then. It was only after implementing finite even/odd rules in Noda Time that I found it wasn't enough.)</div><div><br></div><div>Jon</div><div><br></div></div><div class="gmail_extra"><br><div class="gmail_quote">On 19 July 2015 at 23:02, Paul Eggert <span dir="ltr"><<a href="mailto:eggert@cs.ucla.edu" target="_blank">eggert@cs.ucla.edu</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="">Jon Skeet wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
in Noda Time I could probably support non-infinite rules with a fixed<br>
set of types (hopefully just odd and even), but it would be a bit of work.<br>
If type values are effectively obsolete, I may not bother.<br>
</blockquote>
<br></span>
As far as I know, these haven't been used for some time in tzdata. They do not work with Fedora 21 port of zic, or with Ubuntu 15.04's port, because Fedora and Ubuntu do not install the 'yearistype' command. They mostly work in Solaris, but only because Solaris modifies zic.c by hardcoding the special values "even", "odd", "uspres" and "nonpres".<br>
<br>
If we wanted to support these values portably, I imagine we'd have to implement them the Solaris way. Instead, how about if we document them as obsolescent, as in the attached proposed patch? We needn't change the implementation, so that the obsolete usage should continue to work on whatever platforms install yearistype.<br>
</blockquote></div><br></div>