From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on inbox.vuxu.org X-Spam-Level: X-Spam-Status: No, score=-3.2 required=5.0 tests=DKIM_SIGNED,DKIM_VALID, DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI, RCVD_IN_DNSWL_MED,RCVD_IN_MSPIKE_H4,RCVD_IN_MSPIKE_WL, T_SCC_BODY_TEXT_LINE autolearn=ham autolearn_force=no version=3.4.4 Received: from second.openwall.net (second.openwall.net [193.110.157.125]) by inbox.vuxu.org (Postfix) with SMTP id AF26228734 for ; Tue, 5 Mar 2024 05:32:14 +0100 (CET) Received: (qmail 9519 invoked by uid 550); 5 Mar 2024 04:28:20 -0000 Mailing-List: contact musl-help@lists.openwall.com; run by ezmlm Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-ID: Reply-To: musl@lists.openwall.com Received: (qmail 9484 invoked from network); 5 Mar 2024 04:28:20 -0000 DKIM-Filter: OpenDKIM Filter v2.10.3 mail.cs.ucla.edu 455893C011BD9 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cs.ucla.edu; s=9D0B346E-2AEB-11ED-9476-E14B719DCE6C; t=1709613119; bh=MoUKntnBptLuytluF+HebIA7lA79YZJnYPoH07A2XOg=; h=Message-ID:Date:MIME-Version:To:From; b=Te4Ub8YIhvWNqmtgskSccciMLem0A5EdkiBst0zh95drHxztPB7Mk+gkasMDwWla0 V4lxczUt8YKWw8fmzvw4u6Na+G81Bpi8EzOOg4jm0Pj7/vHfVVSy51l2VhGwVXYtYS 1tLpElGDoGgAoLKAbUvi9+wnAx5WiALrQnOa9I7uFIXAWNuEzZcvVoJVA0rAYgOmf0 cQwArx/CB01TT2h5bnSqNaZcViSzhkCGalxDJgwAO7iKpEXf5z4nv+p/ZVwDZDDFH3 pz8Rrh/7KkjG4Lz7PEfCH5hRu+kz9t12rHEuABYA0TxB713grcUrgpsCoIhNmFTS5c Oy4K5QlV74i7A== X-Virus-Scanned: amavis at mail.cs.ucla.edu Message-ID: <0620fe7a-d3e7-42a0-b65e-f61979cacd22@cs.ucla.edu> Date: Mon, 4 Mar 2024 20:31:58 -0800 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Content-Language: en-US To: =?UTF-8?B?xJBvw6BuIFRy4bqnbiBDw7RuZyBEYW5o?= , Russ Allbery Cc: musl@lists.openwall.com, tz@iana.org References: <87edcqv69m.fsf@hope.eyrie.org> From: Paul Eggert Organization: UCLA Computer Science Department In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: quoted-printable Subject: [musl] Re: [tz] Weird PST8PDT and EST5EDT behavior on Alpine Linux On 3/4/24 19:52, =C4=90o=C3=A0n Tr=E1=BA=A7n C=C3=B4ng Danh via tz wrote: > But seems like nothings was enforced if rule isnot given in the > timezone, which makes it open to intepretion. >=20 > Musl inteprete that as no transition at all [2]. Thanks, that explains things. TZDB has a TZDEFRULESTRING setting that=20 specifies the transitions in this situation; it defaults to US rules, so=20 musl and TZDB always disagree about TZ settings like TZ=3D'PST8PDT'. In TZDB, though, TZDEFRULESTRING is not used for PST8PDT and EST5EDT, as=20 these are one of a small set of Zones that emulate the old System V=20 behavior except with later US law changes taken into account. Another way to put it: for musl the two settings TZ=3D'PST8PDT' and=20 TZ=3D'pst8pdt' agree except for the case of time zone abbreviations, and=20 neither TZ setting ever uses daylight saving time. For TZDB, though, those two TZ settings agree only back to 2007; for=20 earlier timestamps, TZ=3D'PST8PDT' follows historical US behavior for=20 standard time (and thus agrees with TZ=3D'America/Los_Angeles' for all=20 timestamps after 1883-11-18 at noon) whereas TZ=3D'pst8pdt' disagrees wit= h=20 historical behavior by assuming current (2007 and later) rules for DST=20 transitions before 2007. These behaviors all conform to POSIX.