[tz] Invalid tm handling in %s pattern in strftime

[enh]

On Mon, Jun 6, 2022 at 2:53 PM Garrett Wollman via tz <tz at iana.org> wrote:

> <<On Mon, 6 Jun 2022 14:41:15 -0700, Paul Eggert via tz <tz at iana.org>
> said:
>
> > On 6/6/22 13:25, enh wrote:
> >> int saved_errno = errno;
> >> errno = 0;
> >> if (mktime() == -1 && errno != 0) {
>
> > That isn't portable, because mktime can set errno and then successfully
> > return -1, which means the caller can't rely on errno to decide whether
> > mktime succeeded. I'm pretty sure this sort of behavior can happen on
> > popular platforms.
>
> The general rule for POSIX (and ISO C) interfaces is that unless
> specified otherwise, a standard library interface may never set errno
> to zero.  As Paul notes, only some interfaces are explicitly specified
> to leave errno unchanged; those that are not so specified may set it
> to any nonzero value on success.  The current POSIX standard
> definition of mktime() specifies only the permissive "may set errno to
> indicate the error" (as an extension to the C standard) and does not
> require that errno be preserved on success.  So portable applications
> cannot assume that errno will be meaningful even when mktime() does
> experience an error.
>

that's what it used to say (because, as eggert said, ISO C only has that
weak guarantee), but the *current* POSIX text is stronger:

The mktime() function shall return the specified time since the Epoch
encoded as a value of type time_t. If the time since the Epoch cannot be
represented, the function shall return the value (time_t)-1 [CX] [Option
Start]  and set errno to indicate the error. [Option End]

https://pubs.opengroup.org/onlinepubs/9699919799/functions/mktime.html

(the "CX" option is how POSIX says "we deviate from ISO C here".)


> -GAWollman
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mm.icann.org/pipermail/tz/attachments/20220606/c656d717/attachment.html>