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 [216.205.24.124]) by sourceware.org (Postfix) with ESMTP id 3DB033857C68 for ; Wed, 4 Nov 2020 18:37:34 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.3.2 sourceware.org 3DB033857C68 Received: from mail-pf1-f197.google.com (mail-pf1-f197.google.com [209.85.210.197]) (Using TLS) by relay.mimecast.com with ESMTP id us-mta-371-YG1E4OkcMDaFKPD1nbO--A-1; Wed, 04 Nov 2020 13:37:23 -0500 X-MC-Unique: YG1E4OkcMDaFKPD1nbO--A-1 Received: by mail-pf1-f197.google.com with SMTP id a24so8468905pfo.3 for ; Wed, 04 Nov 2020 10:37:23 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=EnRU/hIz1XlzWVn+hB60J1pT6516nJN6xDY1RNP+ijA=; b=DHn1zx/Gvoqdi8sonq45wwEr1hWC5BO5GgxFGH7Yzb4zRbw4V9dgpohBwajmssQrdB yN7+KjbG9bCmmrX6eiE76M57twlSimcorhwIviRBG2wrgRMH/T/bHBpC1l+Ml9PZMlfs pmpoi9PmYUCOaFpLMgpTSRj+Nl/Qnzzukk6kUrxQChsA09AtfTpjGHUdzzmJ0WsNWHet TPhXyK9xrjNqr49QEB1lgkhxmS8vQ9YqCIH38ntqwo/+x/YywD9VKXrzsn4e+NvREN0Q HOdN06Rg+zZOHN17z4Q4Jk5omnD0mU6xuY6TX9pxaBn6u86G8UbxKeUerJD6fo43I0gf FCHA== X-Gm-Message-State: AOAM531wWrJVaLEBUtvJ33WLq8z9U8+Ird4ZmWwv3LtFHNIoAFOI/dho hNfN78CY6xOqHmmYwpQB5Euak0Evhx7YvrbUNKzB9pZPmemzcRuFzLhYLoVYLQ/ulYxB2kUhjQB qsgydWql71/TqfhQAO5PpEDFxUxQhWVw= X-Received: by 2002:a17:90a:ab86:: with SMTP id n6mr5715105pjq.82.1604515042215; Wed, 04 Nov 2020 10:37:22 -0800 (PST) X-Google-Smtp-Source: ABdhPJyv0fF5NJxChImcSZ6UENSthlrMZjYymIboZMwc2QdigDgREInJLSCGH8edgvwT20QODPkctDRY1GpFs6iSreM= X-Received: by 2002:a17:90a:ab86:: with SMTP id n6mr5715088pjq.82.1604515041965; Wed, 04 Nov 2020 10:37:21 -0800 (PST) MIME-Version: 1.0 References: <5d87b235-f246-1bab-f225-484c6fd93b4d@ubero.nl> <12D9D3EC-281D-4D29-A4BD-2FDF39188849@espressif.com> In-Reply-To: <12D9D3EC-281D-4D29-A4BD-2FDF39188849@espressif.com> From: Jeff Johnston Date: Wed, 4 Nov 2020 13:37:11 -0500 Message-ID: Subject: Re: Bug in UTC -> localtime conversion after 2038 To: Ivan Grokhotkov Cc: Udo de Boer , Craig Howland via newlib X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com X-Spam-Status: No, score=-10.7 required=5.0 tests=BAYES_00, DKIMWL_WL_HIGH, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, DKIM_VALID_EF, GIT_PATCH_0, HTML_MESSAGE, KAM_NUMSUBJECT, RCVD_IN_DNSWL_NONE, RCVD_IN_MSPIKE_H4, RCVD_IN_MSPIKE_WL, SPF_HELO_NONE, SPF_PASS, TXREP autolearn=ham autolearn_force=no version=3.4.2 X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on server2.sourceware.org Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.29 X-BeenThere: newlib@sourceware.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Newlib mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Nov 2020 18:37:35 -0000 Thanks Ivan. I added the patch manually as you didn't attach it, but made you the author. Patch applied. -- Jeff J. On Wed, Nov 4, 2020 at 11:21 AM Ivan Grokhotkov via Newlib < newlib@sourceware.org> wrote: > > > > On 4 Nov 2020, at 12:36, Udo de Boer wrote: > > > > [External: This email originated outside Espressif] > > > > Hi, > > > > UTC time to local timezone conversion did not work for years after 2038= . > > Daylight saving in the timezone was not recognized. Tested on 32bit > > xtensa architecture with GCC 8.4 (esp32) and with 64bit time_t enabled. > > > > The struct tm is filled correct. So year, day etc are all filled with > > the correct values. But the tm.tm_isdst is 0 and no daylight saving is > > applied. > > > > It was caused by the following calculation in time/tzcalc_limits.c at > > line 68 > > > > /* store the change-over time in GMT form by adding offset */ > > tz->__tzrule[i].change =3D days * SECSPERDAY + > > tz->__tzrule[i].s + tz->__tzrule[i].offset; > > > > Here tz->__tzrule[i].change is a time_t (64bit). For some reason the > > compiler does the calculation in 32 bit. All variables used in the > > calculation are 32bit. > > > > I solved this locally by changing the lines to. > > > > /* store the change-over time in GMT form by adding offset */ > > tz->__tzrule[i].change =3D (time_t)days * SECSPERDAY + > > tz->__tzrule[i].s + tz->__tzrule[i].offset; > > > > Adding the cast time_t should not cause a problem when time_t is still > > 32bit. > > > > I don't know if this is correct solution. I also only needed this > > function. So more bugs like this could be hidden away in the time code. > > > > > > > > > > > > > > > > > Thank you for reporting and proposing the fix! > Espressif will include this into the next esp32 toolchain release. > > For the convenience of the maintainers, I=E2=80=99ve attached the patch b= elow. > > > Best regards, > Ivan Grokhotkov > > > > From 782c19cd861479cf09a4e2ee27bb7fec1872c626 Mon Sep 17 00:00:00 2001 > From: Ivan Grokhotkov > Date: Wed, 4 Nov 2020 16:49:51 +0100 > Subject: [PATCH] newlib: libc: fix 32-bit integer overflow when > calculating TZ > rules > > --- > newlib/libc/time/tzcalc_limits.c | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/newlib/libc/time/tzcalc_limits.c > b/newlib/libc/time/tzcalc_limits.c > index e0ea6549c..00044a5d3 100644 > --- a/newlib/libc/time/tzcalc_limits.c > +++ b/newlib/libc/time/tzcalc_limits.c > @@ -66,7 +66,7 @@ __tzcalc_limits (int year) > } > > /* store the change-over time in GMT form by adding offset */ > - tz->__tzrule[i].change =3D days * SECSPERDAY + > + tz->__tzrule[i].change =3D (time_t) days * SECSPERDAY + > tz->__tzrule[i].s + tz->__tzrule[i].offset; > } > > -- > 2.21.0 (Apple Git-122) > > > > > >