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
>
>
