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.