Date: Mon, 07 Nov 2022 21:04:49 +0700
From: Robert Elz <k...@munnari.oz.au>
Message-ID: <12822.1667829...@jacaranda.noi.kre.to>
Replying to my own message....
| Date: Sun, 6 Nov 2022 17:31:59 +0000
| From: David Holland <dholland-t...@netbsd.org>
| Message-ID: <Y2fvj/+e7oox4...@netbsd.org>
| | There is nothing in the C99 description of mktime (or
| | POSIX either) that specifies which fields it uses,
|
| I don't know what's in the C standards, but in POSIX that is specified.
Since then Mouse has sent me the mktime() section from his late C99
draft (I assume) of the C standard.
In this area it is close to 100% identical to the POSIX spec, and specifies
that mktime() uses the same fields of struct tm as POSIX does in the
same way (POSIX clearly copied the text from the C standard...)
POSIX:
| The mktime( ) function shall convert the broken-down time,
| expressed as local time, in the structure pointed to by timeptr,
| into a time since the Epoch value with the same encoding as that
| of the values returned by time( ). The original values of the
| tm_wday and tm_yday components of the structure shall be ignored,
| and the original values of the other components shall not be
| restricted to the ranges described in <time.h>.
C:
[#2] The mktime function converts the broken-down time,
expressed as local time, in the structure pointed to by
timeptr into a calendar time value with the same encoding as
that of the values returned by the time function. The
original values of the tm_wday and tm_yday components of the
structure are ignored, and the original values of the other
components are not restricted to the ranges indicated
above.
That is, my earlier analysis of why this does specify the fields
that mktime() uses, and exactly what they are, remains, but now
instead of applying only to the POSIX, applies to both POSIX and C.
It also turns out that the C standard has an important paragraph
that's missing from the POSIX standard. This has no bearing whatever
on strftime() - it concerns the struct tm that results from a
call to mktime() (and so has some relevance for posix issue #1614,
which is 100% unrelated to strftime) but I include it here for
the benefit of any future readers of this thread.
[#3] If the call is successful, a second call to the mktime
function with the resulting struct tm value shall always
leave it unchanged and return the same value as the first
call. Furthermore, if the normalized time is exactly
representable as a time_t value, then the normalized broken-
down time and the broken-down time generated by converting
the result of the mktime function by a call to localtime
shall be identical.
Note that even though mktime() is called by strftime, the struct tm
passed to mktime() is (must be) a copy of the one passed to strftime().
The strftime() arg has the const qualifier (a pointer to a const struct tm)
so strftime is not permitted to modify it. On the other hand, mktime()
is permitted, perhaps even required to modify the struct tm passed to
it (which obviously does not have the const qualifier).
Hence strftime must make a copy of the struct and pass that to mktime().
No modifications made by mktime() to the struct passed to it are
returned to the caller of strftime, nor are they used in any other
way by strftime - strftime just uses the return value (if it doesn't
indicate an error) to provide the value to be converted to a string
to produce the %s result.
kre
