Closed drtobster closed 8 years ago
@@ master #50 diff @@
==========================================
Files 256 256
Lines 10729 10729
Methods 0 0
Messages 0 0
Branches 2047 2047
==========================================
Hits 8317 8317
Misses 1994 1994
Partials 418 418
Powered by Codecov. Last updated by 320ff7e...fe344e9
Thank you, Toby. I appreciate the detailed explanation and the fix. This timezone stuff is not easy. :)
Fixes #49
The logic for converting to UTC from a local time and from UTC to a local time in method
TimeUtils.convert
has been updated. Once the milliseconds from the Epoch has been obtained, those milliseconds and the relevant timezone are passed to methodtoDateTimeValue(long millisFromEpoch, TimeZone zone)
inTimeUtils.java
for conversion to aDateTimeValue
type. That method converts the milliseconds from the Epoch into aGregorianCalendar
type first. This steps takes care of all timezone offsets adjustments as well as handling the DST "gap" and "overlap" hours when applicable.The implementation in BiWeekly version 0.4.6 did not always return the expected value under certain circumstance. This became apparent when using the
advanceTo
method on aDateIterator
with specificstartAt
andTimeZone
values. See Issue #49 for an example.The implementation of
TimeUtils.convert
in versions 0.4.5 and earlier does not contain this problem. However, aDateIterator
in those earlier versions does not handle the DST "gap" hour correctly. See Issue #38.