Thanks for that. Looking at the code, 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@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@pobox.com> wrote:

I'm just going through my Noda Time 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