Re: [HACKERS] Copy from/to asymmetry

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