Paul Eggert <[email protected]> writes:

> On 2026-06-15 21:33, Collin Funk wrote:
>> Paul, what do you think? This feels like a bug in BSD to me, but I
>> certainly trust your opinion here more than mine.
>
> It's a poorly-specified part of the POSIX spec, updated in
> POSIX.1-2024 but still with gaps. I prefer the tzcode/Gnulib
> interpretation as it matches what programmers typically expect. I have
> heard arguments that the BSD interpretation is required by POSIX (for
> compatibility back to POSIX.1-2017 and earlier, which did not require
> tm_gmtoff), but I don't buy them. I do think that the BSD behavior is
> allowed by POSIX, unfortunately.

Right, that is my understanding as well. I wasn't confident in it
though, since I don't use the time interfaces much and there are a bunch
of oddities there.

> How does GNU 'date' end up relying on BSD strftime %z? Doesn't GNU
> 'date' use gnulib nstrftime, and doesn't that do the right thing with
> %z?

I had the same question as well, and was hoping you knew, to be honest. :)

>From what I remember, we defer a lot of things to the underlying system
interfaces on NetBSD. As you know, they generally have good time
interfaces, e.g., tzalloc, localtime_rz, mktime_z. I'm not too sure
about the others.

Anyways, no problem, I can look into it. I may just comment out the test
or disable it on BSD if I don't get around to it before the next CI run.

Collin

Reply via email to