Re: Time Zone design issues

Ha ha that's a funny and accurate way of putting it! I am deploying on a
linux box, so it's good to know this.

But 'apps all know to adjust for TZ'; really? In this case I'm creating the
app, I can't imagine that it will automatically know to adjust for TZ? The
postgres function now() would output now as far as the server is concerned
(per it's local time setting I suppose), but very surprising is there is
enough magic to report to user time as adjusted to their time zone as
recorded in the db?

Ron Johnson wrote:
>
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> On 09/09/07 22:29, novnov wrote:
> [snip]
>>
>> But it doesn't particularly make sense to set the server's clock to UTC.
>> It'd seem to skew a lot of server functionality which I'd think should
>> normally be geared around local time. So I'd guess that the route to take
>> is
>> to keep the server pegged to local time, and use a function that derives
>> UTC
>> from now(), tags the 'last modified' fields with that value.
>
> Your single-user Windows mindset is shining brightly.
>
> Unix servers have had their internal clocks set to UTC for a decade
> or more, and there have been no noticeable ill effects, since apps
> all know to adjust for TZ.
>
> - --
> Ron Johnson, Jr.
> Jefferson LA USA
>
> Give a man a fish, and he eats for a day.
> Hit him with a fish, and he goes away for good!
>
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.6 (GNU/Linux)
>
> iD8DBQFG5MfXS9HxQb37XmcRAuf5AKDKm9h0AxznSTJ0fJx7KzVqFDblYACfeSUV
> Lub89IZdWSIfvGhUZde/jG0=
> =3+7a
> -----END PGP SIGNATURE-----
>
> ---------------------------(end of broadcast)---------------------------
> TIP 2: Don't 'kill -9' the postmaster
>
>

--
View this message in context: http://www.nabble.com/Time-Zone-design-issues-tf4411984.html#a12594326
Sent from the PostgreSQL - general mailing list archive at Nabble.com.