[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <fa8fe53a-0cfe-4e73-b3e4-03ee9a0ee8d2@pgbackrest.org>
Date: Tue, 03 Jun 2025 21:52:43 +0000 (UTC)
From: David Steele <david@...ackrest.org>
To: Markus Wichmann <nullplan@....net>, musl@...ts.openwall.com
Subject: Re: Possible issue formatting epoch time with strftime()
On 6/3/25 11:03, Markus Wichmann wrote:
> Am Mon, Jun 02, 2025 at 07:33:41PM +0000 schrieb David Steele:
>> Ubuntu 22.04 (UTC) gcc:
>>
>> local epoch: 1573222014
>> utc epoch: 1573240014
>> local time: 20191108-090654
>> utc time: 20191108-140654
>>
>> [...]
>>
>> Alpine 3.21 (America/New_York or UTC) gcc/musl:
>>
>> local epoch: 1573222014
>> utc epoch: 1573222014 <------
>> local time: 20191108-090654
>> utc time: 20191108-140654
>>
>
> I think what happened here is that musl is currently implementing
> non-standard extension behavior that is no longer conforming as of last
> year. My reading of POSIX-2024 is that strftime() is to treat the
> incoming timestamp as local time, at least for the purpose of a %s
> conversion. Which it isn't at the moment. But POSIX-2018 did not
> specify %s at all, so musl was allowed to do whatever until POSIX-2024.
Interesting -- thanks for the analysis.
The only place this appears is in our unit tests so we can just remove
it and add an assert to ensure we don't accidentally use it in core.
I did want to bring it up, though, just in case it needed to be fixed.
Thanks,
-David
Powered by blists - more mailing lists
Confused about mailing lists and their use?
Read about mailing lists on Wikipedia
and check out these
guidelines on proper formatting of your messages.
