Re: [HACKERS] Copy from/to asymmetry - Mailing list pgsql-hackers

From Michael Robinson
Subject Re: [HACKERS] Copy from/to asymmetry
Date
Msg-id 200001130551.NAA77189@netrinsics.com
Whole thread Raw
In response to Re: [HACKERS] Copy from/to asymmetry  (Thomas Lockhart <lockhart@alumni.caltech.edu>)
List pgsql-hackers
Thomas Lockhart <lockhart@alumni.caltech.edu> writes:
>> EncodeDateTime,
>> on the other hand, blindly spits out whatever the operating system gives it
>> from localtime().
>
>Yup. afaik this is the only way to get daylight savings time info
>since there is no api to do so otherwise. Since this is the very first
>report of this style of timezone, I don't feel too guilty, and it will
>be easy to fix (I hope anyway).

The GMT+8 format is part of the POSIX standard (at least according to 
the zoneinfo source file).  In the meantime, I've created a new zoneinfo 
file with ISO "+0800" format, as a workaround.  (To make matters worse, I
discovered that POSIX GMT+8 == ISO -0800 ; in other words, the semantics of
the sign character are reversed in the two standards.)

>>   1.  x == datetime_in(datetime_out(x)) should always be true for all valid x.

>Impossible to do apriori, given that we rely on the system to provide
>timezone info for output. However, we try to fix all unusual cases,
>and afaik there are no reasonable formats we have rejected for
>support.

Perhaps, if the system supports strptime(), this function could be used as
a last-ditch effort by ParseDateTime before returning an error.  That would
solve all cases where the datetime_in timezone equals the system timezone
setting.

Or, maybe just use strptime() outright.  I don't know, it's just a suggestion.
-Michael Robinson



pgsql-hackers by date:

Previous
From: Thomas Lockhart
Date:
Subject: Re: [HACKERS] Re: Informix and OUTER join syntax
Next
From: Zeugswetter Andreas SB
Date:
Subject: AW: [HACKERS] Re: Regress tests reveal *serious* psql bug