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