[swbz 29035] mktime vs non-DST
Paul Eggert
eggert@cs.ucla.edu
Wed Aug 17 23:10:22 GMT 2022
On 8/17/22 14:18, DJ Delorie wrote:
> if you set tm_isdst=1 in a call to mktime(), it figures out the
> local DST offset and applies it regardless of timezone rules.
Actually, mktime doesn't and never did that in general, because in
general there's no such thing as the "local DST offset": within a single
TZ setting the difference between standard time and DST need not be
constant. For example, if we are currently in standard time, it's
possible that the next spring-forward will add 30 minutes, while the
previous fall-backward subtracted an hour. In such a situation the
"local DST offset" could reasonably be thought of as 30 minutes, or 60
minutes, or even something else if there were other transitions of
varying sizes at other times.
Although I'm not seeing how BZ#29035 led to your diagnosis (Andreas
didn't reproduce that bug), we did run into a similar problem in Gnulib,
and I installed into Gnulib a patch to fix that. So I suggest syncing
with Gnulib. This is a bit fancier than what you suggested, but I expect
it'll fix BZ#29035 while it's also fixing the bug reported against Gnulib.
Proposed glibc patches attached. Their effect is to sync glibc from
Gnulib. If these patches don't fix the problem you diagnosed please let
me know.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 0001-Assume-HAVE_TZSET-in-time-mktime.c.patch
Type: text/x-patch
Size: 709 bytes
Desc: not available
URL: <https://sourceware.org/pipermail/libc-alpha/attachments/20220817/bca2f855/attachment.bin>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 0002-mktime-improve-heuristic-for-ca-1986-Indiana-DST.patch
Type: text/x-patch
Size: 3198 bytes
Desc: not available
URL: <https://sourceware.org/pipermail/libc-alpha/attachments/20220817/bca2f855/attachment-0001.bin>
More information about the Libc-alpha
mailing list