On Fri, Aug 10, 2007 at 04:59:52PM -0400, Tom Lane wrote:
> Karsten Hilbert <Karsten.Hilbert@gmx.net> writes:
> > On Fri, Aug 10, 2007 at 10:11:29AM +0200, Louis-David Mitterrand wrote:
> >> So if I understand correctly, a timestamp_tz is ...
>
> > ... stored as UTC in the backend
>
> > ... sent to clients shifted by whatever timezone was
> > requested by the client by one of several mechanisms:
>
> > - "set timezone to ..." used by the client
> > - "select ... at time zone ..." used by the client
> > - the server timezone if neither of the above is used
>
> The other point to be clear on is that the "shifting" is done according
> to whatever timezone rule files the server currently has. Since
> politicians keep changing daylight-savings rules, the same UTC date/time
> might be displayed differently after an update of the relevant rule
> file.
(I am located in Paris, GMT+2, using debian unstable)
When using "date" here is the output on the server where the postgresql
upgrade (or more likely that's server's subsequent misconfiguration)
changed our timestamps:
uruk:~# date
Sat Aug 11 10:50:46 CEST 2007
uruk:~# date --utc
Sat Aug 11 08:50:49 UTC 2007
uruk:~#
and:
uruk:~# tzconfig
Your current time zone is set to Europe/Paris
But, I found something fishy that particular server:
uruk:~# hwclock
Sat 11 Aug 2007 10:47:36 AM CEST -0.630123 seconds
uruk:~# hwclock --utc
Sat 11 Aug 2007 12:47:39 PM CEST -0.600430 seconds
Whereas on my other servers "hwclock --utc" displays the same time
(is that normal?):
zenon:~# hwclock
Sat 11 Aug 2007 10:50:21 AM CEST -0.015345 seconds
zenon:~# hwclock --utc
Sat 11 Aug 2007 10:50:24 AM CEST -0.000235 seconds
Is postgres using the same time reference as "hwclock" or "date" ?
Thanks,
