On 2024-01-12 00:02, Robert Elz wrote:
| If I understand things correctly, it's impossible for an implementation | to conform to both POSIX-2017 and draft next POSIX in this area.
What do you believe the problem to be?
On reflection I spoke too quickly and these appear to be awkward wordings and misinterpretations rather than conformance issues. Still, the awkwardnesses deserve discussion. POSIX 202x/D3 and the latest C2x draft (n3096) can both plausibly (but in my view incorrectly) be interpreted to say that strftime cannot look at tm_gmtoff or tm_zone, which is obviously wrong for tzcode, as well as for glibc, FreeBSD, and I assume other strftime implementations. To work around this problem, it'd be helpful if draft POSIX (at least) were fixed to clearly state the interpretation I proposed earlier today <https://mm.icann.org/pipermail/tz/2024-January/033524.html>. It'd also be helpful if draft POSIX were changed to state the following: * For %c and %X, strftime can look at tm_gmtoff and tm_zone. * For %s, strftime can look at tm_gmtoff. * For %Z, strftime can look at tm_zone. * For %z, strftime can look at tm_gmtoff and tm_zone. (tm_zone is useful when tm_gmtoff == 0, since it helps distinguish +0000 from -0000.) This would better reflect existing and reasonable practice. Less importantly, POSIX and C both say that strftime can look at struct tm members that aren't needed once you have tm_gmtoff and tm_zone (and in some cases aren't needed even if you have those two new members). POSIX should make it clear that the implementation need not look at these members. * For %c, %s, %Z and %z, strftime need not look at tm_isdst. * For %U, strftime need not look at tm_year. * For %X, strftime need not look at tm_year, tm_yday, tm_mon, tm_mday, tm_wday, tm_isdst. * For %x, strftime need not look at tm_hour, tm_min, tm_sec, tm_gmtoff, tm_zone, tm_isdst. To try to document all this better from tzcode's point of view, I installed the attached proposed patch to tzcode's strftime man page.