It appears all we have to do is remove the addition of the timezone
information in setTimestamp(n, ts)
and leave it for setTimestamp(n, ts, cal)
This only fails our internal tests at +- infinity which is tractable.
Dave
On 19-Jul-05, at 10:27 PM, Dave Cramer wrote:
>
> 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
>>
>>
>>
>
>
> ---------------------------(end of
> broadcast)---------------------------
> TIP 3: Have you checked our extensive FAQ?
>
> http://www.postgresql.org/docs/faq
>
>