Re: work in progress: timestamp patch
От | Dave Cramer |
---|---|
Тема | Re: work in progress: timestamp patch |
Дата | |
Msg-id | 7E3F468F-93C8-4082-9248-B9B52020E5F9@fastcrypt.com обсуждение исходный текст |
Ответ на | Re: work in progress: timestamp patch (Oliver Jowett <oliver@opencloud.com>) |
Ответы |
Re: work in progress: timestamp patch
Re: work in progress: timestamp patch |
Список | pgsql-jdbc |
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 > >
В списке pgsql-jdbc по дате отправления: