[tz] Type values in rules

[Jon Skeet]

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.

For finite rules, the years in which they're valid can easily be expanded
(possibly at the cost of readability).

Looking back a bit further, back in the *early* 90s the Adelaide zone ended
up with rules like this:

Rule AS 1987 max - Oct lastSun 2:00 1:00 -
Rule AS 1990 max even Mar Sun>=22 3:00 0 -
Rule AS 1990 max odd Mar Sun>=1 3:00 0 -

>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.

(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.)

Jon


On 19 July 2015 at 23:02, Paul Eggert <eggert at cs.ucla.edu> wrote:

> Jon Skeet wrote:
>
>> in Noda Time I could probably support non-infinite rules with a fixed
>> set of types (hopefully just odd and even), but it would be a bit of work.
>> If type values are effectively obsolete, I may not bother.
>>
>
> 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".
>
> 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.
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mm.icann.org/pipermail/tz/attachments/20150720/eeb23aa4/attachment.html>