On 21-Jul-05, at 8:54 PM, Tom Lane wrote:
> Oliver Jowett <oliver(at)opencloud(dot)com> writes:
>> i.e. currently the core of the problem is this behaviour:
>> template1=# select '2005-01-01 15:00:00
>> 2005-01-01 18:00:00
>> (1 row)
> Well, the current interpretation is that timestamptz -> timestamp
> produces a timestamp representing what the timestamptz equates to in
> your current TimeZone. I do not foresee changing that behavior
> we add explicit TZ info to timestamptz --- it would break just about
> every existing app that uses this conversion.
> In any case, this wouldn't solve Christian's complaint, because the
> of his problem is that the value ever goes through timestamptz at all.
> That is necessarily going to "munge" values that don't correspond to
> legal local times in whatever zone you are using.
> The more I think about this, the more I think that the correct
> must include having the driver set TimeZone = UTC (and complain if the
> app tries to change it).
This really isn't an option. We can't impose limits on the
application like this.
> Then you can specify parameter types as either
> timestamp or timestamptz, it doesn't really matter, because
> between them on the server side will be no-ops. When you convert a
> Timestamp to send to the server, you always convert it using a UTC
> Calendar object. I'm not sure if the setTimestamp variants with a
> Calendar are special in this regime; arguably you should ignore the
> supplied Calendar, on the principle that you know what the
> Timestamp is
> supposed to mean.
> regards, tom lane
> ---------------------------(end of
> TIP 3: Have you checked our extensive FAQ?
In response to
pgsql-jdbc by date
|Next:||From: Tom Lane||Date: 2005-07-22 13:42:34|
|Subject: Re: Timestamp Conversion Woes Redux |
|Previous:||From: Dave Cramer||Date: 2005-07-22 12:45:42|
|Subject: Re: Timestamp Conversion Woes Redux|