Oliver,
Dave
On 25-Jul-05, at 11:19 PM, Oliver Jowett wrote:
> Dave Cramer wrote:
>
>
>> I've been messing with it a bit myself, and noticed that
>> TimeStampUtils.toString used the timezone of the incoming
>> timestamp, not the calendar. So the call to appendTimeZone, passes in
>> the timestamp, not the new calendar.
>>
>
> Yeah, looking at the stringizing TimestampUtils code is my next step.
> I've just overhauled the parsing side of things to correctly use
> passed
> Calendars (for getTimestamp() and friends)
>
>
>> Also I've added functionality to track the servers's timezone so that
>> stmt.execute("set timezone='newtimezone'") allows you to
>> programatically set the server timezone to UTC. Which would be
>> necessary to get Christian's problem to work even using
>> Oid.INVALID ( I
>> think )
>>
>
> I don't think it's necessary to track the server timezone at all..
> what's the case where this goes wrong?
One of the times he is trying to stick in the db is a non-existant
time if it is associated with a
time zone
stmt.execute("INSERT INTO Foo (t1) VALUES ('2005-04-03 02:29:43.0')");
in any US timezone this time does not exist. In US/Mountain timezone
this
inserts as 2005-04-03 03:29:43.0' note the hour has incremented from
2 to 3
The only way to insert this time correctly is to use UTC
>
> I'll send you an updated version of my patch offlist (it's changing
> fairly fast at the moment so I'll avoid spamming the list with every
> revision)
Ok, I'll test it in the morning... Thanks
>
> -O
>
>
