diff options
author | Kaz Kylheku <kaz@kylheku.com> | 2023-02-13 17:58:50 -0800 |
---|---|---|
committer | Kaz Kylheku <kaz@kylheku.com> | 2023-02-13 17:58:50 -0800 |
commit | 8d54fdb9967429c46c8dc84d1c07d994b5c79856 (patch) | |
tree | b92bcf6d096e089ed9f20b46d31c5b9ee2a3c1b9 /sysif.h | |
parent | 53586222a4184fcbb72c993efeab8fd7ae74bbee (diff) | |
download | txr-8d54fdb9967429c46c8dc84d1c07d994b5c79856.tar.gz txr-8d54fdb9967429c46c8dc84d1c07d994b5c79856.tar.bz2 txr-8d54fdb9967429c46c8dc84d1c07d994b5c79856.zip |
time: respect gmtoff in calculating numeric time.
We have the following problem. On some platforms, the broken-down
C time structure "struct tm" has a GMT offset field which
gives the time zone of the specified time. In the Lisp
structure, we call the corresponding slot gmtoff.
This value should be taken into account when converting
the broken-down time to a numeric time value.
The underlying platform functions like mktime don't do this;
they not only ignore the gmtoff, but in some cases clobber
the field.
The GNU C library version of the POSIX strptime function
supports "%z" and "%Z" specifiers which populate the GMT
offset. But then it gets wrongly ignored.
Old/wrong behavior:
1> (time-parse-utc "%H:%M:%z" "00:00:+0900")
0
New behavior (on platforms with the GMT offset):
1> (time-parse-utc "%H:%M:%z" "00:00:+0900")
32400
* time.c (time_meth): If the Lisp time structure we are given
specifies a non-nil gmtoff, then add its value
to the returned result.
(time_parse_local, time_parse_utc): If struct tm has a
GMT offset, then we add its value to the time_t returned
by mktime, timegm or timegm_hack.
* txr.1: Updated.
Diffstat (limited to 'sysif.h')
0 files changed, 0 insertions, 0 deletions