Thread: Re: [Keystone Slip # 22] Some confusion with datetimedata type andtimezone

> I'm sending individual E-mail because I think this subject should not be
> discussed in mailing list.

It is appropriate for the mailing list, so try that next time please.

> I just thought that external representation(output) of datetime should be
> the same as input.
> Does anybody agree that the following behavior is correct ?
...
> Depending on timezone, the hour will be changed.

Yes, I believe that the behavior is correct. But I implemented the
code ;)

You can suppress any timezone shifting by running your backend in GMT
by setting your system time zone or by setting PGTZ. You can also set
PGTZ for any client using libpq (e.g. psql), or do a 'set time zone'
from your app.

An alternative is to use the "date" data type, which does not carry
time zone info.

> I solved this problem just cutting the timezone ID in the application, when
> needed, because if dttest < ??/??/1901 or dttest>??/??/2037 (abstime limits)
> no timezone ID is showed.

Right. The conversion to local time can only happen if the underlying
system can help do the conversion. Also, for times in the past the
conventions for time zones and daylight savings time were much more
fluid and unsettled, and who knows what they will be in the future?

I hope this helps...
                       - Thomas

-- 
Thomas Lockhart                lockhart@alumni.caltech.edu
South Pasadena, California