[tz] strftime %s

[Paul Eggert]

On 2024-01-15 01:38, Robert Elz wrote:

>    | Although it's overkill for the POSIX strftime spec to require
>    | struct tm components to be set when they don't need to be set,
> 
> You're missing the point of it all.  The components that it lists
> are what some correct implementations need to be set to function.

I'm not missing the point; I'm trying to clarify and/or fix it.

POSIX has never required implementations to look at every listed struct 
tm member to function correctly in every use of the corresponding 
conversion spec. Nor has it required that the result of the conversion 
spec be completely determined by the contents of the struct tm members. 
The relation between the struct tm member values and the conversion 
outputs is more subtle than that.


>    | it's not that big a deal. In practice nearly
>    | every app calls strftime on the result of localtime etc.
> 
> Is there some evidence to support that?

Sure, look at tzcode. Or at coreutils. Or at Emacs. Or at 'tar'. Or at 
pretty much every app that uses strftime. Although it's theoretically 
possible that there are exceptions for the edge cases we're talking 
about, so far in this thread we've seen zero real-world examples.


> why would you penalise those other apps which don't?

I'm not trying to *penalize* any unusual code that trips over these edge 
cases. I'm trying to *help* it. If code relies on bugs or incorrect 
interpretations of odd corners of the POSIX spec, it'll get wrong 
answers. Standards should be worded clearly to help prevent this sort of 
confusion.


> But yes, once the next POSIX is published, then the tm_gmtoff field
> will be available to %z and tm_zone to %Z, and simply using those
> will be easy to do.   Of course, if you do it that way, you're
> breaking any existing applications which were written to either
> conform to the C standards (any of them)

No, it doesn't break conforming C programs that use these oddball edge 
cases. The C standard doesn't specify how the implementation determines 
the timezone. It can be TZ or it can be something else. So even if the 
behavior changes, it's not a violation of the C standard, as a 
conforming C program will still work as the C standard requires.


>    | All that's needed is for strftime
>    | to compute seconds since the Epoch in the usual way (i.e., using the
>    | Gregorian calendar and ignoring leap seconds),
> 
> But aside from correcting for out of range values, which strftime is
> not required to do, that's eactly what mktime() is specified to do.

That's a pretty big aside....

The intent of this part of the strftime spec, as I see it, is to say 
that strftime should use the standard POSIX way of breaking down time 
(Gregorian, no leap seconds) - not all the other mktime machinery.


> That UTC offset *must* come from the TZ value, such that if TZ is
> altered to refer to some other offset, then the result from mktime()
> (and hence from strftime(%s)) must change.

This is incorrect for two reasons. First, changing TZ need not alter 
mktime's result. Second and more important, even if you *don't* change 
TZ, two calls to mktime can yield different answers for the same 
in-range inputs, so the POSIX 202x/D4 spec does not completely specify 
strftime's output.

This second property is inherent to the inadequacy of mktime's API. And 
it undercuts any argument that strftime %s and mktime must always 
produce exactly the same output.


> But by all means, submit a defect report, and see how far that gets
> you.

OK, I've done that here:

https://www.austingroupbugs.net/view.php?id=1797

It uses an example that is a bit sharper that what we've discussed so 
far, in that the example exploits abovementioned inadequacy of mktime's API.