Details
-
Type:
Test
-
Status:
Open
-
Priority:
Major
-
Resolution: Unresolved
-
Affects Version/s: None
-
Fix Version/s: None
-
Component/s: jdbc-postgis plugin, jdbc-sqlserver plugin
-
Labels:None
Description
The tests fail (the superclass is JDBCDateTest) on the first assertion (though now that I look at it, the second assertion is the same...) - expected 2, got 1.
Looking into this further, the issue lies with the TemporalConverterFactory.timeMillisToDate. This method introduces a timezone offset (equivalent to default timezone offset) into the value and the resulting generated SQL uses the day earlier - at least in my timezone ![]()
It appears that some work done in this method is superfluous at best and most likely incorrect (at least in this code path).
The javadoc for java.sql.Date(long) constructor notes that the driver will truncate the insignificant fields and present the value as 00:00:00 GMT (so all of these acrobatics appear superfluous). When this code is removed and the milliseconds constructor is used directly (without any calendar acrobatics), the tests pass. Likewise, when the calendar GMT timezone is removed, the tests pass. Similarly, with the removal of the 'set' methods, but leaving the GMT calendar timezone in place, the tests pass. It appears that the set methods use the local timezone to compute a new date based upon GMT 00:00:00 (which in my case, would be the day before)
Looking at the various values present in this code path (as it stands):
(the date in the test case):
initial millis 1246168800000
offset 360 (in seconds)
date.toString Sun Jun 28 00:00:00 MDT 2009
(in the converter):
convert before : 1246168800000
convert after 1246147200000
The difference in the above is 21600000 (or 360 seconds - my local offset)
I'd guess that this was added in an attempt something else work...