New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Failure to include "end of year" transitions #335

Closed
GoogleCodeExporter opened this Issue Mar 15, 2015 · 3 comments

Comments

Projects
None yet
2 participants
@GoogleCodeExporter

GoogleCodeExporter commented Mar 15, 2015

This is a real corner case, and I think it's already fixed in 2.0, but it means 
we'd be building a broken nzd file into 1.3.1.

Asia/Dakha has two rules for 2009:

Rule    Dhaka   2009    only    -   Jun 19  23:00   1:00    S
Rule    Dhaka   2009    only    -   Dec 31  24:00   0   -

When working out the transitions in Noda Time 1.x, we'd find the local time of 
the first transition after the current interesting instant, and check that the 
year to see if it's in range.

For the "2009 Dec 31st 24:00" transition, the local time is actually Jan 1st 
2010... but that's outside the range of the 2009 rule, if we use the actual 
local time. We should use the "local time before adding the day" instead, I 
think.

Original issue reported on code.google.com by jonathan.skeet on 12 Nov 2014 at 8:30

@GoogleCodeExporter

This comment has been minimized.

Show comment
Hide comment
@GoogleCodeExporter

GoogleCodeExporter Mar 15, 2015

This issue was closed by revision 37273e52c6c8.

Original comment by jonathan.skeet on 12 Nov 2014 at 9:39

  • Changed state: Fixed

GoogleCodeExporter commented Mar 15, 2015

This issue was closed by revision 37273e52c6c8.

Original comment by jonathan.skeet on 12 Nov 2014 at 9:39

  • Changed state: Fixed
@GoogleCodeExporter

This comment has been minimized.

Show comment
Hide comment
@GoogleCodeExporter

GoogleCodeExporter Mar 15, 2015

Note that this is fixed as far as 1.3.1 is concerned. The code in 2.0 is 
entirely different, and I think it's potentially still broken. As it happens, I 
suspect that the way PrecalculatedDateTimeZone works, we'll never run into the 
issue, but I'd like to understand it...

Original comment by jonathan.skeet on 12 Nov 2014 at 9:47

  • Changed state: Started

GoogleCodeExporter commented Mar 15, 2015

Note that this is fixed as far as 1.3.1 is concerned. The code in 2.0 is 
entirely different, and I think it's potentially still broken. As it happens, I 
suspect that the way PrecalculatedDateTimeZone works, we'll never run into the 
issue, but I'd like to understand it...

Original comment by jonathan.skeet on 12 Nov 2014 at 9:47

  • Changed state: Started
@GoogleCodeExporter

This comment has been minimized.

Show comment
Hide comment
@GoogleCodeExporter

GoogleCodeExporter Mar 15, 2015

Reclosing for 1.3.1; redirecting 2.0 investigation work to issue 347.

Original comment by malcolm.rowe on 27 Feb 2015 at 10:52

  • Changed state: Fixed
  • Added labels: Milestone-1.3.1
  • Removed labels: Milestone-1.3.1-consider

GoogleCodeExporter commented Mar 15, 2015

Reclosing for 1.3.1; redirecting 2.0 investigation work to issue 347.

Original comment by malcolm.rowe on 27 Feb 2015 at 10:52

  • Changed state: Fixed
  • Added labels: Milestone-1.3.1
  • Removed labels: Milestone-1.3.1-consider

@malcolmr malcolmr added the bug label Mar 15, 2015

@malcolmr malcolmr modified the milestone: 1.3.1 Mar 15, 2015

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment