Re: Unit test patches

Kris Jurka wrote:
> John Lister wrote:
>
>> for all of these i do this first:
>> Time t=new Time(28862000); // this should be 8:01:02 UTC
>>
>> Now the odd bit
>> Europe/London (DST auto-adjust enabled but not active) - 09:01:02
>> - This is wrong, it should be equiv to GMT
>
> Yes, but not at the unix epoch. See the section titled "Permanent
> summer, 1968–1971"
>
> http://www.nmm.ac.uk/explore/astronomy-and-time/time-facts/british-summer-time/
>
I assumed that something was going on around the epoch, but didn't
realise that - amazing what you learn about your own country.

Still there is bizarre behaviour with the java time stuff (nothing new
there then...)

Assuming timezone=Europe/London then

TimeZone t=TimeZone.getDefault();
t.inDaylightTime(new Date(28862000L)) == false
t.getRawOffset() == 0
t.getOffset(28862000L) == 3600000

It would seem that inDaylightTime doesn't take into account historical
stuff...

Anyway patch attached that fixes the problem for all (tested)
timezones.. Can you let me know how you get on...

Also, for the failing test - I'm fairly sure the driver shouldn't be
inserting "9:01:02" for the value of "5:1:2+03" when the current
timezone is "Europe/London" without DST - as it uses the epoch to
calculate the offsets which while historically correct are now
incorrect. Note that setting it to simply GMT works as expected.

I suspect that the date component should be initialised to the current
date instead of 1/1/1970 for internal manipulation within the driver and
reset before returning anything to the user as a sql.Time value.

Thoughts

JOHN