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