Re: [swbz 29035] mktime vs non-DST

[Carlos O'Donell <carlos@redhat.com>]

On 8/17/22 21:39, DJ Delorie via Libc-alpha wrote:
> Paul Eggert <eggert@cs.ucla.edu> writes:
>> Although I'm not seeing how BZ#29035 led to your diagnosis
> 
> We had a customer bz with a similar problem.  I wrote a script to test
> every transition in every zoneinfo file, plus a january/june check, for
> every tm_isdst.  The patterns tend to jump out at you after that.
> 
>> 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.
> 
> 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.  I think this makes it more consistent, but I don't know
> what the consequences of "different than before" will be here.
 
Different than before is problematic because of existing code expectations.

The mktime() interface has been around for a long time and users do not expect
and have noticed the semantic changes we are seeing here today.

I would lean towards making the code do exactly what it did before in these
corner cases (unless we don't consider them corner cases).

May you please share some examples you have from your analysis and share how
they are different before and now? How far back does the old behaviour go?

-- 
Cheers,
Carlos.