[tz] Transitions specified for February 29th

[Jon Skeet]

Thanks for that. Looking at the code
<http://www.ietf.org/timezones/code/zic.c>, it seems that:

   - It *is* valid to specify Feb 29th if it's just in a single year which
   is a leap year
   - It's valid to specify Feb 29th even for a non-leap year, so long as
   we're moving to an earlier day-of-week value (we could even end up on Feb
   22nd, for example). (It's not entirely clear to me that that's a good idea,
   but...)

I think I can probably encode both of those rules fairly easily in my C#
code - and the "move to the next leap year" rule is definitely wrong...

Jon



On 7 July 2014 20:33, Arthur David Olson <arthurdavidolson at gmail.com> wrote:

> Script started on Mon, Jul 07, 2014  3:31:25 PM
> $ cat fake
> Rule    Fake    2014    max    -    Feb    29    2:00    1    D
> Rule    Fake    2014    max    -    Oct    31    3:00    0    S
>
> Zone    Fake    0    Fake    F%sT
> $ ./zic fake
> "fake", line 4: use of 2/29 in non leap-year (rule from "fake", line 1)
> $ exit
> Script done on Mon, Jul 07, 2014  3:31:32 PM
>
>     @dashdashado
>
>
> On Mon, Jul 7, 2014 at 3:09 PM, Jon Skeet <skeet at pobox.com> wrote:
>
>> I'm just going through my Noda Time <http://nodatime.org> code for time
>> zone handling, and I've noticed I'm being even more defensive than normal,
>> by handling the situation where a time zone transition is specified to
>> occur on the 29th of February - I skip forward or backwards to the nearest
>> leap year.
>>
>> This feels like it's overkill to me, and that it would be better just to
>> prohibit this situation from occurring in my code, *if* it's widely
>> accepted to be invalid data.
>>
>> Is there anything specifying the behaviour if such data is presented? I
>> could try running the zoneinfo compiler myself, but I suspect it would take
>> a long time to get all the tools sorted, and I wouldn't be certain of
>> interpreting the outcome properly. If anyone just *knows,* that would
>> save me a lot of effort :)
>>
>> Jon
>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mm.icann.org/pipermail/tz/attachments/20140707/f59ad0d9/attachment.htm>