summaryrefslogtreecommitdiffstats
path: root/args.c
diff options
context:
space:
mode:
authorKaz Kylheku <kaz@kylheku.com>2023-02-13 17:58:50 -0800
committerKaz Kylheku <kaz@kylheku.com>2023-02-13 17:58:50 -0800
commit8d54fdb9967429c46c8dc84d1c07d994b5c79856 (patch)
treeb92bcf6d096e089ed9f20b46d31c5b9ee2a3c1b9 /args.c
parent53586222a4184fcbb72c993efeab8fd7ae74bbee (diff)
downloadtxr-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 'args.c')
0 files changed, 0 insertions, 0 deletions