Re: Timestamp Conversion Woes Redux
От | Dave Cramer |
---|---|
Тема | Re: Timestamp Conversion Woes Redux |
Дата | |
Msg-id | 468CE7D4-3BFC-48D8-BC94-3AA73950EBED@fastcrypt.com обсуждение исходный текст |
Ответ на | Re: Timestamp Conversion Woes Redux (Oliver Jowett <oliver@opencloud.com>) |
Ответы |
Re: Timestamp Conversion Woes Redux
Re: Timestamp Conversion Woes Redux |
Список | pgsql-jdbc |
On 19-Jul-05, at 10:02 PM, Oliver Jowett wrote: > Dave Cramer wrote: > >> Christian suggested this: >> >> However I think this too opaque. >> > > Why do you think this? There's no timezone information associated > with a > Timestamp, so it seems like the logical mapping: if you provide a > timezone via Calendar, it's a timestamp-with-timezone; otherwise, > it's a > timestamp-without-timezone. Well, we're in a vague area of the spec here. There are two TIMESTAMP types defined by the sql spec, and only one setTimestamp. There is no indication by the spec that this behaviour is the "right" behaviour. > > >> Not to mention the fact that it changes the >> current behaviour. >> > > Err, given that the current behaviour is broken, is this a problem? Well, depends on what we break by "fixing" it. I still have access to the box and can re-run the cts to make sure it still passes. > > Every time I've looked at the timestamp code I've gone "ow, that > has to > be broken" but never got around to investigating further .. IMO, > this is > an area that the driver just gets *wrong* and we should be fixing > it so > it works, not trying to support applications that expect the wrong > behaviour! > Interestingly enough I implemented PGTimestamp, and PGTimestamptz and ran his test case. It passed in both cases and did the right thing. I'm still investigating why. Dave > -O > >
В списке pgsql-jdbc по дате отправления: