Commit 30f64ec added a fix for #9 to handle timezones where the offset is a non-integer number of hours, such as Asia/Kolkata (UTC +5.30). However, the fix still produces incorrect results for any timezone whose UTC offset, expressed in fractional hours, requires more than 2 significant digits to represent.
The problem comes from the conversion to milliseconds to hours using BigDecimal.divide(3600000, new MathContext(2)). Here, MathContext(2) was probably used to indicate "two decimal places", but actually means "two significant digits" (including the integer part).
Affected timezones:
- Any timezones with quarter-hour offsets (e.g. Asia/Kathmandu, Australia/Eucla, Pacific/Chatham).
- Any timezones with half-hour offsets where the integer part is two digits (e.g. Australia/Lord_Howe).
| Timezone |
Offset |
Computed |
Correct |
Error |
Asia/Kathmandu |
+5:45 |
5.8 |
5.75 |
+3 min |
Australia/Eucla |
+8:45 |
8.8 |
8.75 |
+3 min |
Australia/Lord_Howe |
+10:30 |
11 |
10.5 |
+30 min |
Pacific/Chatham |
+12:45 |
13 |
12.75 |
+15 min |
Commit 30f64ec added a fix for #9 to handle timezones where the offset is a non-integer number of hours, such as Asia/Kolkata (UTC +5.30). However, the fix still produces incorrect results for any timezone whose UTC offset, expressed in fractional hours, requires more than 2 significant digits to represent.
The problem comes from the conversion to milliseconds to hours using
BigDecimal.divide(3600000, new MathContext(2)). Here,MathContext(2)was probably used to indicate "two decimal places", but actually means "two significant digits" (including the integer part).Affected timezones:
Asia/KathmanduAustralia/EuclaAustralia/Lord_HowePacific/Chatham