JtdsPreparedStatement setTime setTimestamp Daylight DST Bug - ID: 1176221
We had tests set up to test whether the date/times inserted into a SQL Server 2005 over this daylight saving changeover period were correct. We found they were correct except for a 1 hour block between 4th October 2009 1300-1400 (AEST) or 4th October 0200-0300 (GMT). These were always stored one hour ahead.
I had a look at the source code, I think the problem lies in the method Support.timeFromZone(java.util.Date value, Calendar target)After reading through this thread, I gather the purpose of this method was to convert the Date object value to a UTC long. This long will have the equivalent 'wall' time in the local time zone as value has in the time zone stored in the Calendar object target.
Problems arise when the 'wall' time contains values that cannot be represented in the local timezone. In our example, since daylight saving in Sydney begins at 4th October 2009 0200 (clocks shift forward one hour to 0300), the period from 0200-0300 does not a valid date/time for the timezone AEST. Hence when Support.timeFromZone encounters dates that have a wall time that lie in this period (i.e. 4th October 0200-0300 (GMT)) , the static Calendar object Support.cal shifts the hour-of-day field 1 hour forward resulting in all dates in this period being stored in the database 1 hour forward.
Attached is a JUnit test case that fails on v 1.2.4
Log in to post a comment.