[swbz 29035] mktime vs non-DST
Paul Eggert
eggert@cs.ucla.edu
Thu Aug 18 03:02:35 GMT 2022
On 8/17/22 18:39, DJ Delorie wrote:
> It does stop mktime from returning -1 in the problem case, but it still
> returns a different value than pre-2.29. Older code returned the
> standard time result, your patches return a DST result, even if the zone
> has no DST.
Actually, the old (glibc 2.28) code could return a standard time result
even in zones with DST, and this led to results that weren't
self-consistent.
For example, suppose we use the attached program to ask mktime "What
time is it in Fiji on July 1 at 00:00 DST for the two years 2029 and
2030?" Although Fiji no longer observes DST (it stopped last year), the
old glibc code does this:
2029-07-31 23:00:00 +1300 +13
2030-08-01 00:00:00 +1300 +13
whereas Gnulib (and glibc with the proposed patches) does this:
2029-07-31 23:00:00 +1300 +13
2030-07-31 23:00:00 +1300 +13
The old code is inconsistent with itself, because it gets confused by
the DST that Fiji stopped observing in in 2021. The new code is
consistent with itself, as well as with similar questions asked about
New York, Los Angeles, etc. when you ask for a DST during a day that DST
is not observed.
There is no perfection in this area because the mktime API is busted
(though POSIX may improve it if they listen to me :-). That being said,
the Gnulib mktime behavior should be better than the old glibc behavior
for the great majority of users.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: uu.c
Type: text/x-csrc
Size: 497 bytes
Desc: not available
URL: <https://sourceware.org/pipermail/libc-alpha/attachments/20220817/d5d8db5d/attachment.bin>
More information about the Libc-alpha
mailing list