[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