Date: Tue, 22 Nov 2022 12:49:13 +0000
From: "Geoff Clare via austin-group-l at The Open Group"
<austin-group-l@opengroup.org>
Message-ID: <Y3zFSV/bW8mrpgTb@localhost>
| Having returned refreshed from my break, I have re-examined this issue
| and I now have a clear understanding of why the C standard allows
| mktime() to return -1 for times in the gap but POSIX does not.
I sent Geoff a much longer reply to this message than this one - but once
again neglected to add a cc to the list. He's welcome to forward that
message if he feels inclined. It touched upon almost all the points of his
message (you will have seen from my earlier reply here today, that the
tzdata error will be corrected) - but it really just boils down to this.
| Okay, let's examine the text in C89/C90:
|
| 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.
| [...]
|
| Returns
| The mktime function returns the specified calendar time encoded as
| a value of type time_t. If the calendar time cannot be represented,
| the function returns the value (time_t)-1.
|
| (In C99 and C17 it is the same except for additional parentheses
| around "-1").
|
| This wording is almost identical to POSIX, except for "shallification",
| the use of "time since the Epoch" in POSIX instead of "calendar time" in
| C99, and the POSIX requirement to set errno.
Yes, they are essentially the same, hence if -1 is allowed from C,
it is also allowed for POSIX.
| However, there is a big difference in the requirements that arise from
| these almost identical wordings, and that is because local time and DST
| are implementation-defined in C, but in POSIX they are not.
XBD 4.17
The relationship between the actual time of day and the current
value for seconds since the Epoch is unspecified.
POSIX specifies that local time needs to exist, and that summer time
is possible, and provides a mechanism to indicate when summer time
begins and ends (if it exists), but that's it. Everything else, as
it says there is unspecified.
| In order for a non-POSIX implementation of mktime() to return (time_t)-1
| for a time in the gap, all it has to do is define local time and DST in
| such a way that times in the gap are converted to a value that cannot be
| represented in a time_t. For example, it could say they are converted
| to UINT64_MAX if time_t is a signed 64-bit integer type. Then the
| requirement in the C standard would kick in, requiring mktime() to
| return (time_t)-1 because UINT64_MAX can't be represented in that time_t
| type.
I very much doubt that's the reasoning they used, but if they did, the
exact same reasoning is available in POSIX, with the exact same conclusing,
and as POSIX is deferring to the C standard (very explicitly in the case
of mktime()) if C says that -1 is an OK return, then -1 is an OK return.
| This "loophole" is not present in POSIX because local time and DST are
| not implementation-defined.
Nonsense. See above. (What they are is explicitly unspecified, which
is even looser than implementation defined.)
The time_t value cannot be represented, as it does not exist, or is
ambiguous, and the implementation has been given no guidance which of
several possible values applies. In either case, returning -1 is an
entirely reasonable thing to do, and much better than picking some
random time_t value and returning that instead.
kre
