Unexpected result with DST gap in 1916 and timezone "Europe/Berlin" #582
Description
Key information
- Joda-Time version: 2.10.13
- Result of
TimeZone.getDefault(): sun.util.calendar.ZoneInfo[id="Europe/Berlin",offset=3600000,dstSavings=3600000,useDaylight=true,transitions=143,lastRule=java.util.SimpleTimeZone[id=Europe/Berlin,offset=3600000,dstSavings=3600000,useDaylight=true,startYear=0,startMode=2,startMonth=2,startDay=-1,startDayOfWeek=1,startTime=3600000,startTimeMode=2,endMode=2,endMonth=9,endDay=-1,endDayOfWeek=1,endTime=3600000,endTimeMode=2]] - Result of
DateTimeZone.getDefault(): Europe/Berlin
Problem description
We are getting unexpected results when hitting a DST gap in combination with dayOfMonth().withMaximumValue() at the very end of April, 1916. This was actually the first DST ever in Germany jumping from 1916-04-30T23:00:00.000+01:00 to 1916-05-01T00:00:00.000+02:00, if we are not mistaken.
When adjusting the given date of 1916-04-01T23:59:59.999+01:00 (TimeZone "Europe/Berlin") using dayOfMonth().withMaximumValue() we hit the DST gap.
The JavaDoc for withMaximumValue() states the following:
From v2.2, this method handles a daylight savings time gap, setting the time to the last instant before the gap.
This would lead us to expect a result of 1916-04-30T22:59:59.999+01:00.
However, the output is: 1893-03-31T23:59:59.999+00:53:28.
This is completely off and resulted in an infinite loop during calculations for due dates of contracts in one of our applications. 😯
Test case
@Test
public void test_JodaDSTBug() throws Exception {
DateTime problemDate = DateTime.parse("1916-04-01T23:59:59.999").withZone(DateTimeZone.forID("Europe/Berlin"));
DateTime endTime = problemDate.dayOfMonth().withMaximumValue();
Assert.assertEquals("1916-04-30T22:59:59.999+01:00", endTime.toString());
}