From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mout.perfora.net (mout.perfora.net [74.208.4.196]) by sourceware.org (Postfix) with ESMTPS id 386073857811 for ; Wed, 4 Nov 2020 12:59:28 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.3.2 sourceware.org 386073857811 Authentication-Results: sourceware.org; dmarc=none (p=none dis=none) header.from=Damon-Family.org Authentication-Results: sourceware.org; spf=none smtp.mailfrom=Richard@Damon-Family.org Received: from [192.168.77.198] ([108.20.19.251]) by mrelay.perfora.net (mreueus003 [74.208.5.2]) with ESMTPA (Nemesis) id 0Lhy56-1jvzkS4ByU-00nA71 for ; Wed, 04 Nov 2020 13:59:27 +0100 Subject: Re: Bug in UTC -> localtime conversion after 2038 To: newlib@sourceware.org References: <5d87b235-f246-1bab-f225-484c6fd93b4d@ubero.nl> From: Richard Damon Message-ID: <2ff07bdd-d9d2-b761-023e-c41f3ee1905f@Damon-Family.org> Date: Wed, 4 Nov 2020 07:59:26 -0500 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:78.0) Gecko/20100101 Thunderbird/78.4.0 MIME-Version: 1.0 In-Reply-To: <5d87b235-f246-1bab-f225-484c6fd93b4d@ubero.nl> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit Content-Language: en-US X-Provags-ID: V03:K1:vE3SBZvylENiUUOOy/rAi8IsS7PluG0684Zxg4I1cvYgs4fFwRP dsio5Hxp+/MlDe2aiXsQFarZGtUFSrv7+DulOfHCceotof2XbLTs/MkVYfwzdIZtth7StxC l69HY0KEtdpH+fgatvnCb+mO6sElhSi8SHEtSls5o+rySx6IH1TNOulVkiwjj97eQDtB+Pf +JCvCQCqhwi72p+pYfOLw== X-UI-Out-Filterresults: notjunk:1;V03:K0:mj/eLTnU8Gs=:BBAg/7xBZF8Fc8yXUwiSi7 ZvzK0uFv1pkGkDC0a/pQhkbmHLrqXowDdADo0q0cGmQfHaYw9VHUJUuaBErn8+loyNb+sn9h5 bVs8Dlq2lYZT6Y61oi9q41E0Sd6ME8ZbWoTQlMIoyRy1LK34Itvlc8euTCwHSl2WMQSNo9kw6 MSe46bA4SjYOu4YMp5ZUhf742Ot58bxM16Nh0RpPrxUP1N6fcbbC8DFduiWw+XKSaG/E0fkYk htKFFbhmKmiLphZ6z1+6meOIrqMe/EfHpBrSp9v834+c+soJtoyiWwDdiyIHZo/DBDR1yXuYD 65EFh12HvEHF3U4gFwe8BlivhbX9aALI/LuQcXsKxQ41nTEt3heiQSFI6DmYLbdC+iQPq8ljR ASPSwqb7u7XUoZFbZU8jDaSwZTE/w2uQAxQe1OBWJFKAtquv0rYhFN4nRQYSqVIWFDZnv5Qw5 YJ4R51Solw== X-Spam-Status: No, score=0.9 required=5.0 tests=BAYES_00, BODY_8BITS, KAM_DMARC_STATUS, KAM_LAZY_DOMAIN_SECURITY, KAM_NUMSUBJECT, NICE_REPLY_A, RCVD_IN_DNSWL_NONE, RCVD_IN_MSPIKE_H2, SPF_HELO_PASS, SPF_NONE, TXREP autolearn=no autolearn_force=no version=3.4.2 X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on server2.sourceware.org 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 12:59:30 -0000 On 11/4/20 6:36 AM, Udo de Boer wrote: > 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 = 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 = (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. > C arithmetic is defined based on the size of the operands, not the destination, so math on 32 bit quantities is done at 32 bits (unless int is bigger, as int is the smallest size used). The casting of one of the operands to the bigger size is the right solution. -- Richard Damon