Re: [musl] Possible issue formatting epoch time with strftime()

Re: [musl] Possible issue formatting epoch time with strftime()

[Markus Wichmann]

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.

Ciao,
Markus

Re: [musl] Possible issue formatting epoch time with strftime()

[David Steele]

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