Zone lines parsed incorrectly about nodatime HOT 10 CLOSED

Can you give any specific examples of this offhand, just so I can find it 
easily? Will then work on it before the 1.0 release.

For example Asia/Tbilisi is one that has zone lines like this:
  3:00 E-EurAsia    GE%sT   1994 Sep lastSun

America/Pangnirtung has zone lines with the second format:
  -4:00 NT_YK   A%sT    1995 Apr Sun>=1 2:00

Thanks - will have a look and see if Joda Time has been changed to support 
this. We're still close enough to their code base to make that the best option 
:)

Assigning to James for the moment, as he's done rather more on the TZ side than 
I have.

Reassigning to Jon.

Hmm. We definitely *do* have at least some support for "last" and ">=" - it's 
in TzdbZoneInfoParser, currently line 285. It looks like it's been there right 
from the start.

I'm currently seeing some problems with the Tbilisi time zone around 1997, when 
Noda Time says that DST ended on Feb 28th then started again on March 30th. So 
we've got some issues there, but the rest of the transitions match what Joda 
Time is telling me. I haven't tried Pangnirtung yet.

When you say "This of course results in errors" - what errors were you getting? 
Which version of Noda Time were you using? Can you attach a sample program?

Anyway, this has brought up the issue of 1997 at the very least, so it's 
definitely useful :)

(Just checked, and Pangnirtung has a similar problem, this time in 1995 and 
2007.)

Yeah, I see that there is some code for last and >=, but as far as I can tell 
it is only used in ParseRule and not in ParseZoneLine.

I was using 858:e1efbe66710b.

I was looking into some conversion errors, where converting local time to utc 
was giving different results in joda time and noda time. Some of these errors 
was with Asia/Tbilsi.

The following timezones were wrong for any local date I tried:
EST,GMT+N,HST,MST,Pacific/Johnston - I suspect these were fixed with issue #28, 
but I have not verified it yet.

There were sporadic errors in the time zones listed in the attached CSV file. I 
think these are the ones caused by this zone line parsing bug.

So these were errors as in incorrect results, not errors as in exceptions, 
correct?

I've just come to the same conclusion - that basically the same sort of logic 
should be in ParseLine. I'm just trying to work out how to fix it now... 
Unfortunately I won't be able to do much more today, but at least I think we're 
on the same page now :)

> So these were errors as in incorrect results, not errors as in exceptions, 
correct?

Correct, no exceptions, just incorrect results compared to jodatime.
I also double-checked some of these with timezoneconverter.com and they matched 
jodatime's results.

Fixed in revision bc932931ecbe - thanks so much for pointing it out.

Will open an issue with a scheme to hopefully provide a longer lasting fix, 
assuming Joda Time is correct...