From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.133.124]) by sourceware.org (Postfix) with ESMTPS id C9C8E3858D37 for ; Thu, 18 Aug 2022 02:37:09 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org C9C8E3858D37 Received: from mail-qk1-f199.google.com (mail-qk1-f199.google.com [209.85.222.199]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.3, cipher=TLS_AES_128_GCM_SHA256) id us-mta-86-JKs6kqX9NJaAbBa_Vgd5rw-1; Wed, 17 Aug 2022 22:37:08 -0400 X-MC-Unique: JKs6kqX9NJaAbBa_Vgd5rw-1 Received: by mail-qk1-f199.google.com with SMTP id n15-20020a05620a294f00b006b5768a0ed0so311704qkp.7 for ; Wed, 17 Aug 2022 19:37:08 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=content-transfer-encoding:in-reply-to:organization:from:references :cc:to:content-language:subject:user-agent:mime-version:date :message-id:x-gm-message-state:from:to:cc; bh=RpS20DqULOCiETk0Sx6Wo6SmlOvfMg14tN5pFR72jXA=; b=VvnnfZmYBXrWMTdOwe9HePSQPDfrhfdtemDIKuakuV3OLMgn+6/aL+Sa9gaVrEjPwJ DRo/zyCAY3M2PU13P/tA+jC6GcVDEu6DsMfLrGhe/TvB+OXB/AkvK9PyPRbnwr3SnGrp hn5PYU/kuaDXHeiSmq7NXwWVin0iVXJydCkIqVBHMyVGOiUoU4ztM+xxirJxzhOpn4vc CC/Wvtsm8h5s8rMTOkedbifC5x6XdCewjswMdLeZ2h7Xe+nc52h33k+owcjMomDry745 fRD5uFgdp7v5BNZNNlO8cHH/lBS6pDSifXZ+Ee4L4rU6XmEgPYKPfp1RiVQOSKq6/nWT i5Rw== X-Gm-Message-State: ACgBeo10bLPr/R6UxnprjBkUqEaMEIldPWLBv+Di2er+3/7/gByvuL8v M/BapZsXV6RIgVwbmOQyeYmqTtDOo1huwmIYzHhoMuR4xe2BxQF/yw8ZeCbP9L/NE6flt25Enkc m2bGVVEK9xqvNyxJEg0+H X-Received: by 2002:a37:9ad4:0:b0:6b9:c5d1:74e2 with SMTP id c203-20020a379ad4000000b006b9c5d174e2mr680205qke.319.1660790227998; Wed, 17 Aug 2022 19:37:07 -0700 (PDT) X-Google-Smtp-Source: AA6agR6/NVX7dEofrVwpHJHne3smTgaOVObK5FSFgjkhQh4r/G0hIFhCtp6zsz0edyB6EpBPD1gC6g== X-Received: by 2002:a37:9ad4:0:b0:6b9:c5d1:74e2 with SMTP id c203-20020a379ad4000000b006b9c5d174e2mr680198qke.319.1660790227774; Wed, 17 Aug 2022 19:37:07 -0700 (PDT) Received: from [192.168.0.241] (192-0-145-146.cpe.teksavvy.com. [192.0.145.146]) by smtp.gmail.com with ESMTPSA id i12-20020ac85c0c000000b0031eb393aa45sm156744qti.40.2022.08.17.19.37.06 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Wed, 17 Aug 2022 19:37:07 -0700 (PDT) Message-ID: <8c91bbc3-95cc-88d0-ffe9-5da08fcfdf38@redhat.com> Date: Wed, 17 Aug 2022 22:37:06 -0400 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:91.0) Gecko/20100101 Thunderbird/91.11.0 Subject: Re: [swbz 29035] mktime vs non-DST To: DJ Delorie , Paul Eggert Cc: libc-alpha@sourceware.org References: From: Carlos O'Donell Organization: Red Hat In-Reply-To: X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Language: en-US Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Spam-Status: No, score=-6.8 required=5.0 tests=BAYES_00, DKIMWL_WL_HIGH, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, DKIM_VALID_EF, NICE_REPLY_A, RCVD_IN_DNSWL_NONE, SPF_HELO_NONE, SPF_NONE, TXREP, T_SCC_BODY_TEXT_LINE autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on server2.sourceware.org X-BeenThere: libc-alpha@sourceware.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Libc-alpha mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 Aug 2022 02:37:10 -0000 On 8/17/22 21:39, DJ Delorie via Libc-alpha wrote: > Paul Eggert 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.