0001614: XSH 3/mktime does not specify EINVAL and should

Notes
(0006022) geoffclare (manager) 2022-11-03 16:54	I'm sure this has been discussed at least once before, but on the mailing list not in Mantis. When the specified time does not exist because it is in the gap created by the change to daylight saving time and tm_isdst is -1, mktime() is not allowed to fail. It must treat the time either as standard time or as daylight time and return the corresponding value. (The value of tm_isdst on output distinguishes the two.) Likewise when daylight saving time ends and times are ambiguous when tm_isdst is -1, mktime() must choose to treat it either as standard time or as daylight time. These cases are tested by one of the UNIX certification test suites. If you know of an implementation where mktime() returns -1 under these conditions, please report it as a bug to the maintainers. Cases such as Singapore and Malaysia moving to a different time zone are another matter, and I suppose mktime() could legitimately return -1. However, this would only happen with a TZ that specifies a location (rather than "std offset dst offset, rule"), and the behaviour of all functions that use TZ is implementation-defined in that case anyway, so I don't see the need to add an EINVAL error to the standard for this.

(0006025) hvd (reporter) 2022-11-03 18:04	> I'm sure this has been discussed at least once before, but on the mailing list not in Mantis. When the specified time does not exist because it is in the gap created by the change to daylight saving time and tm_isdst is -1, mktime() is not allowed to fail. C does allow this to fail; this has been confirmed at <https://www.open-std.org/jtc1/sc22/wg14/www/docs/dr_136.html>. [^] It is valid for POSIX to require specific behaviour in areas that the C standard leaves unspecified, but I see nothing in the CX-marked additions in POSIX specifies the behaviour for this case.

(0006028) kre (reporter) 2022-11-03 20:02 edited on: 2022-11-03 20:48	Re Note: 0006022 I'm sure this has been discussed at least once before, I thought I remembered it as well, but did not find it, but if it was just on the list that would explain it. But that's why I included the first paragraph of the description. But: When the specified time does not exist because it is in the gap created by the change to daylight saving time and tm_isdst is -1, mktime() is not allowed to fail. That makes no sense at all. In the ambiguous case, I guess things could be interpreted that way (the time runs twice), and in that case certainly the tm_isdst value in the result can distinguish which was chosen (that is, the implementation picks one if the application did not bother), but I do not see anything in XSH 3/mktime which actually requires that to happen. Certainly if the user sets tm_isdst to 0 or 1 in this case, then mktime() must not fail, but return the appropriate value, but for the -1 case, all I see in the standard is: A negative value for tm_isdst shall cause mktime( ) to attempt to determine whether Daylight Savings Time is in effect for the specified time. Nothing there about it being required to pick one. Note that text I proposed adding does not prohibit an implementation from picking one and returning that, merely allows EINVAL if the value supplied in tm_isdst is unable to resolve the ambiguity. If an implementation chooses to always pick one or the other (or even roll the die, and randomly return one or the other) that's fine, in that case it used the -1 input and used that to resolve the ambiguity, but I see nothing which requires that kind of result. But for the gap, the period where the local time specified never existed at all, no result (except -1 with errno set) makes any sense at all. The whole idea of mktime() is that localtime() applied to the time_t returned will produce the same struct tm as that left in *timeptr my mktime() after it has completed. The two are inverses of each other (to the extent that EOVERFLOW does not apply, in one direction or the other, anyway). For a broken down time (a struct tm) passed to mktime() which gives a value that localtime() can never produce is simply broken. As best I can tell the standard reference implementation of mktime() acts exactly like this. Lastly, I have no sympathy at all for an argument by which POSIX deliberately says that many places in the world don't need to be handled by the standard TZ definition, and that anything that allows their time zone specification to correctly translate their times is beyond the standard, and anything is permitted, is simply outrageous (though this is not the place to debate XBD 8.3: TZ). But if things happen as they are looking like they might, this kind of issue is likely to occur in the US, and Europe as well, if seasonal variations are abandoned, and localities are permitted to pick which zone they will remain in as their standard time - when that transition happens, and it might not be far away, well before Issue9 of POSIX can possibly appear, this exact problem will occur in places that the POSIX committee people cannot simply dismiss as "we don't care what happens in that part of the world", which seems to be the attitude now.

(0006030) kre (reporter) 2022-11-03 20:27	I meant to add in the previous note (but this is more than I think should be done by just amending that), that an option (not one I believe correct, but if it seems to be) would be that rather than adding EINVAL to the "shall fail" case, at least in the ambiguous input (time runs twice) scenario, that could be added as a "may fail" section following the current "shall fail". For the "time in the never existing gap" case (which exists in all zones which have summer time (also stupidly known as "daylight savings") no matter what form they use to specify the TZ setting, there really is no option, the only thing mktime() can do in that case is return an error, nothing else is correct, that needs to be a "shall fail".

(0006031) geoffclare (manager) 2022-11-04 09:36 edited on: 2022-11-04 10:01	Re Note: 0006025 Yes, POSIX is more strict than C here. The CX shaded text that matters is: A negative value for tm_isdst shall cause mktime() to attempt to determine whether Daylight Savings Time is in effect for the specified time. (C has something similar, but in a non-normative footnote.) As I understand it, this requires that if mktime() determines that DST is in effect, it returns the same result as it would for tm_isdst=1, otherwise it returns the same result as it would for tm_isdst=0. That is how all certified UNIX and POSIX systems behave. Until now I thought it was how all mktime() implementations behave, but I see that the C DR that you cite mentions "Arthur David Olson's popular ``tz'' time zone software" as returning -1. That was back in 1994, so I wonder if it still does or if it has changed to behave like other implementations. Re Note: 0006022 > But for the gap, the period where the local time specified never existed > at all, no result (except -1 with errno set) makes any sense at all. The > whole idea of mktime() is that localtime() applied to the time_t returned > will produce the same struct tm as that left in *timeptr my mktime() after > it has completed. The two are inverses of each other If you just feed in a struct tm obtained from localtime(), or any equivalent source of valid date and time info, obviously the "gap" times will never occur. What you are missing here is that an important feature of mktime() is that you can do calculations using the tm members. That is the reason it specifically allows out-of-range values. If an application uses mktime() to answer the question "What will the date and time be a month from now" (meaning when the wall clock time is the same as it is now, but on the day that is a month from now) by incrementing tm_mon and setting tm_isdst=-1, it is not helpful to get back the answer "that time won't exist". There are probably a very large number of applications that do this kind of thing that will break if ported from an implementation where mktime() does not return -1 to one where it does (if any exist). Worse still, they will only break under rare circumstances, so the problem could go unnoticed for years, decades even, before biting one day. If we did decide to allow mktime() to return -1, ask yourself how would an application handle this error? The vast majority of applications will want to obtain a time they can use, rather than reporting an error; if that time is adjusted by an hour because it happens to occur right at a DST change, that's all well and good. So the obvious way for them to handle the error would be to repeat the mktime() call with tm_isdst=0 (or 1). This will produce the same result that the standard currently requires. So all that allowing this error will achieve is to force most application writers to add another mktime() call in order to get the same result they would have got before. If an application actually wants to verify whether a given time exists, it can so do simply by checking whether the tm_hour and tm_min values it gets back are the same ones it fed in. This is actually a more reliable method than assuming that a return of -1 with errno EINVAL indicates a non-existent time would be (if we allow it), because EINVAL could be caused for other reasons as well (e.g. an invalid TZ value). > For a broken down time (a struct tm) passed to mktime() which gives > a value that localtime() can never produce is simply broken. I'm having trouble parsing that. If you are suggesting that passing the return value of mktime() to localtime() could produce different struct tm member values than those returned by mktime(), then that can never happen, since mktime() is required to set them the same way localtime() does. > As best I can tell the standard reference implementation of mktime() > acts exactly like this What implementation do you believe to be a reference implementation? The function was invented by the ANSI C committee. As far as I'm aware they did not produce a reference implementation. In the absence of an implementation by the function's inventors, all implementations have equal standing and none is a reference implementation. Actually, that's not quite true, because POSIX has additional requirements beyond the C standard, so implementations that only claim conformance to C and not POSIX have no standing in relation to the additional POSIX requirements. > I have no sympathy at all for an argument by which POSIX deliberately > says that many places in the world don't need to be handled by the > standard TZ definition, and that anything that allows their time zone > specification to correctly translate their times is beyond the standard Perhaps we should add the Area/Location TZ format to POSIX (with no details, just a reference to another standard, maybe RFC 6557). Re Note: 0006030 > For the "time in the never existing gap" case [...] there really is > no option, the only thing mktime() can do in that case is return an > error, nothing else is correct, that needs to be a "shall fail". This would make every certified implementation non-conforming, along with most if not all implementations that claim POSIX conformance but aren't certified, and would break many applications. There is absolutely no way this change would achieve consensus.

(0006032) kre (reporter) 2022-11-04 17:37 edited on: 2022-11-04 17:43	Re Note: 0006031 I know this: A negative value for tm_isdst shall cause mktime() to attempt to determine whether Daylight Savings Time is in effect for the specified time. and what your note says about it, but note that it says "attempt to determine" not "determine" which it would not say if it were guaranteed to be able to work (and I don't mean anything related to the unpredictability of what might happen into the indefinite future, all we can possibly do is assume that the current rules apply forever forward, until we discover differently). If that attempt fails, what do you contend that mktime() should do? What you are missing here is that an important feature of mktime() is that you can do calculations using the tm members. I don't think I was missing that, if you look back at the description section, you'll see that it includes an example... It is possible for an implementation to use tm_isdst as a hint to what happened so cases like this work timeptr = localtime(&t); timeptr->tm_min += 20; t = mktime(timeptr); and if you believe that is a requirement, then I don't object to that, but I'd like a pointer to where in the standard this is stated as required. But why would any code do, as you postulate: incrementing tm_mon and setting tm_isdst=-1, why the "setting tm_isdst=-1" part? What would be the point? If tm_isdst remained as localtime set it, then the implementation can use that when normalising the numbers, to deduce what happened if no time_t for the time can be produced, and further push the time through the gap (altering tm_hour). But if we don't know what tm_isdst applied before, how is the implementation supposed to determine whether the tm passed to mktime() was produced by an addition (time moving forwards) as in both your example, and mine, or by a subtraction (looking for an earlier time). The expected result in the two cases will be different (when we are crossing the gap). Paul Eggert's C query (from 1994) referenced by Harald in Note: 0006025 suggests that the test suites look for either of two answers, as long as the implementation produces one of them, all is good. Surely you aren't going to defend that as a practice? "We don't care whether the answer you give is correct or meaningful, just as long as you give an answer"? Really? Surely an error response is always better than an incorrect answer passed off as being correct? There are probably a very large number of applications that do this kind of thing that will break if ported from an implementation where mktime() does not return -1 to one where it does (if any exist). If there is any implementation where mktime() cannot return -1, it is already non-compliant -- the standard is quite clear that mktime() shall return -1 (with errno == EOVERFLOW) in some cases. Any application that doesn't deal with a -1 return from mktime() is already defective, whatever happens here. What the application should do when it gets a -1 I cannot possibly say - it entirely depends upon the needs of the application, but it certainly needs to deal with the possibility (or just hope it never happens, which would be a behaviour that would not need to be changed). So the obvious way for them to handle the error would be to repeat the mktime() call with tm_isdst=0 (or 1). This will produce the same result that the standard currently requires. The question would be why they did not do that the first time? Why are you imagining the tm_isdst=-1 being there? Note that even this cannot handle all the cases (it certainly doesn't help with EOVERFLOW) ? I am not going to debate application code writer's possible behaviours, we don't have enough info to discuss that - using EINVAL to signal "in the gap" as a message to them was never the purpose. Rather it is a necessity for any implementation which seeks to provide only correct answers, rather than "if we do this we pass the validation test, so that's what we do, regardless of how stupid it is". And yes, implementers sometimes do act just like that, under pressure. Do you not see the incongruity of these two comments from your note: If we did decide to allow mktime() to return -1, and EINVAL could be caused for other reasons as well (e.g. an invalid TZ value). The second accepts that (even though it is not in the mktime() page, mktime() can already return -1 with error == EINVAL. But given all of that, note that tzset() is not actually allowed to return an error, what happens with an invalid TZ is apparently unspecified, but tzset() is apparently required to do something in that case, and not return an error. So, I doubt that your "EINVAL could be caused for other reasons as well" is actually the case (not that it matters here, a -1 return from mktime() is possible whatever happens as a result of this issue, including nothing. But hadn't you already decided that mktime() can return -1 ?? (and even with errno==EINVAL) wrt: I'm having trouble parsing that. Sorry, that happens sometimes. If you are suggesting that passing the return value of mktime() to localtime() could produce different struct tm member values than those returned by mktime(), then that can never happen, since mktime() is required to set them the same way localtime() does. what I meant is exactly what you say there is required. And I agree. But mktime() only gets to adjust the input struct tm values (according to what is written in the specification: the other components shall be set to represent the specified time since the Epoch, but with their values forced to the ranges indicated in the <time.h> entry; That is, the "other components" (which means all of the relevant ones, just not tm_wday and tm_yday which are irrelevant here) are set to represent the specified time since the Epoch (that is: the time specified by the caller of mktime()) but with any out of range values (according to what is specified in <time.h>) adjusted so that are in range (and while it does not say so, and probably should, I would interpret that to also mean not having 31 days in November, even though 31 is within the range permitted for tm_mday in <time.h>) but it doesn't say that they can be adjusted for any other reason. If we take Paul's example from C defect report #136 (the 1994 issue cited by Harald in Note: 0006025) and the application create a struct tm, exactly as he described it, what justification exists to allow mktime() to alter any of the fields of the struct tm (except tm_isdst, as a -1 input is never in range as an output value). I see none. If the result is not -1, the resulting tm should be (for the specified fields, other than tm_isdst) be identical to the one supplied. Given that, if mktime() does not return -1 (if it does, what is in the tm seems unspecified to me) then we have a case where mktime is (apparently) required to leave the struct tm in a state which is something that localtime() can never return - violating the requirement that we both agree should exist. On the other hand, if it does return -1, which the C committee apparently agree it can (and yes, I know that posix can make stricter requirements than exist in C ... though I don't see anything in the spec for mktime() which does so - only apparently in the broken validation suites) then this is not an issue. What implementation do you believe to be a reference implementation? I meant the one referenced in that defect report, which is (I believe) by far the most widely used implementation (though often with minor variations) existing at the minute, and is public domain. I believe that android and probably macos both use it, I think all the BSDs use it, and linux. Some of the commercial OSs use it as well. The function was invented by the ANSI C committee. That is news to me, but I cannot dispute it, as I have no idea of its origins. I do have vague memories of it in the very ancient past though. The earliest BSD implementation (taken from the ado code) I can find is in 4.3 Reno (1990) - but it must have existed for quite a while before that, as that contains a version of mktime() based upon one I had done earlier -- using an idea from Bob Kridle, when he was still at UC Berkeley, Computer Centre -- the time_t desired is determined by doing a binary search over the range of a time_t (works for any possible time_t type - including floats) calling localtime on each, comparing its resulting struct tm with the (already normalised) input struct tm (and adjusting the upper or lower bound of the search as appropriate) until equality is found. When it becomes impossible to subdivide the range smaller (we'd need to be producing sub-second intervals) if no match has been found, the tm originally requested, simply cannot exist, and an error happens. When I did my initial implementation of that, which was adopted (modified to suit other requirements) in ado's implementation, I was replacing an earlier algorithmic implementation (kind of like that in XBD 4.16 - but of course, not nearly as simple as that makes it seem). I moved away from unix work in the latter 1980's (87 or so) and more into networking and the IETF for the rest of the century (before that environment became far too political and commercial after the explosion of the internet in the late 1990's). In any case, that would mean that there must have been at least one freely available mktime() implementation around in the mid 1980's. When did the C committee apparently invent it? Aside: the advantage of the binary search algorithm is certainly not speed, it is slower than an algorithmic implementation, usually a lot slower, but it removes any knowledge of time peculiarities from mktime() - works whatever (arithmetic) type time_t happens to be, and always guarantees that one requirement that we agree on, locatime(mktime(tm)) == tm (not that that is anything like valid C, but you know what I am getting at, and the error case is being ignored there - that's only for valid time_t returns). It also works (without adjustment) in environments using UTC, rather than POSIX time_t (ie: where leap seconds are not simply imagined out of existence), not that that aspect is relevant here. While still considering this general point, also note that Paul's C defect message, also includes this sentence: The ANSI C Rationale (corresponding to subclause 7.12.2.3) clearly lets mktime yield -1 in the ``fall-backward fold'' that will occur when the clock is turned back from 01:59:59 to 01:00:00 on October 30, 1994. That's the case I have less problem avoiding a -1 result from, as while it is ambiguous there which time_t is intended, either one will generate the struct tm that was given to mktime() (and the input tm_isdst, if not -1, can be used to select which - though there is no help available when the input tm_isdst == -1) - but this is another case where an error return is apparently allowed by C, the POSIX mktime() spec claims to defer to the C standard, and nowhere (I have found) does POSIX say that it is more restrictive in this area. Where do you believe these additional requirements are stated? I really believe that there is no option other than allowing EINVAL in these cases (if you insist you could make both of them be "may fail if" rather than "shall fail if") which would allow implementations which return nonsense results, just because the (apparently broken) conformance tests require nonsense results, to remain conforming, while still allowing implementations striving for correctness to generate error returns when no correct answer is possible. On this last point: Perhaps we should add the Area/Location TZ format to POSIX (with no details, just a reference to another standard, maybe RFC 6557). That would be a great idea. (Would need a new bug report though, it doesn't belong in this one). "No details" I would agree with, and I'd specify even less than you do there, I'd give some requirements on what must be achieved, but no hints as to how to achieve that. Eg: I believe that windows systems use the timezone data collected by the tz project, (and probably more as well), but make use of it in a completely different way, nothing like what that RFC specifies. No reason to prohibit that, or even suggest it isn't the correct way - as long as it achieves the correct results. What matters is a TZ value, that isn't a valid POSIX TZ string (for what use those are, which isn't much, in any meaningful zone) and doesn't start with a ':' (which should remain as now), will (in an implementation unspecified manner) provide access to information which allows any time_t (ideally since standard time was adopted in a locality, and certainly since the Epoch) to be converted to the appropriate time_t (and back again) using the rules appropriate for that timezone at that particular time. Requiring a '/' in the name isn't required I'd expect, though in practice, all that matter (and aren't also POSIX strings) meet that format.

(0006033) hvd (reporter) 2022-11-04 23:23 edited on: 2022-11-04 23:23	> Re Note: 0006025 Yes, POSIX is more strict than C here. The CX shaded text that matters is: > A negative value for tm_isdst shall cause mktime() to attempt to determine whether Daylight Savings Time is in effect for the specified time. > (C has something similar, but in a non-normative footnote.) Note that this, despite being CX-shaded, is not actually an instance of POSIX being more strict than C. The C footnote, in full, is: "Thus, a positive or zero value for tm_isdst causes the mktime function to presume initially that Daylight Saving Time, respectively, is or is not in effect for the specified time. A negative value causes it to attempt to determine whether Daylight Saving Time is in effect for the specified time." The footnote makes it clear that this is considered to follow from the normative wording and there is therefore no need to have this as a separate requirement in the normative wording; the footnote is merely for clarification. I believe that thinking here is correct. Do you disagree? I'm happy with POSIX choosing to spell this out in normative wording, but if it adds no new requirements, it cannot be the case that it specifies anything that isn't specified by the C standard as well. Either this is unspecified both in ANSI C and in POSIX, or this is defined in both ANSI C and POSIX.

(0006034) geoffclare (manager) 2022-11-07 12:33	Re Note: 0006032 This discussion is becoming too long to hold in bugnotes. See my response on the mailing list.

(0006035) geoffclare (manager) 2022-11-07 12:42	Re Note: 0006033 > The footnote makes it clear that this is considered to follow from the > normative wording and there is therefore no need to have this as a separate > requirement in the normative wording; the footnote is merely for > clarification. I believe that thinking here is correct. Do you disagree? Yes I disagree. The word "thus" is what makes it seems like this follows from normative text, but if you look at the normative text where the footnote marker is, there is nothing there from which the text in the footnote could be derived. So the use of "thus" is puzzling. I believe the real reason that the text is in a footnote instead of normative is because, earlier on, the C standard says "The local time zone and Daylight Saving Time are implementation-defined." Since DST is implementation-defined the C standard can't have normative text requiring mktime() to behave a certain way with regard to DST; it is left to implementations to decide how to interpret tm_isdst. In POSIX the DST rules are specified in the description of TZ, so there is no problem requiring mktime() to make use of them.

(0006036) hvd (reporter) 2022-11-07 12:59	> Yes I disagree. The word "thus" is what makes it seems like this follows from normative text, but if you look at the normative text where the footnote marker is, there is nothing there from which the text in the footnote could be derived. So the use of "thus" is puzzling. There is. The footnote is attached to a sentence that states that the values on entry of tm_wday and tm_yday are ignored and that the other values not limited to their usual ranges. This tells us all values other than tm_wday and tm_yday are used, including tm_isdst. This means the value on entry of tm_isdst must be interpreted according to the earlier definition of tm_isdst, which is (in normative text) "The value of tm_isdst is positive if Daylight Saving Time is in effect, zero if Daylight Saving Time is not in effect, and negative if the information is not available." The only way to use the value on entry of tm_isdst that is consistent with that definition is what the footnote describes. It may not be exactly clear, but it's a legitimate reading and one that the wording in the footnote tells us is the intended reading.

(0006037) geoffclare (manager) 2022-11-08 15:24	Re Note: 0006036 > The only way to use the value on entry of tm_isdst that is consistent > with that definition is what the footnote describes. Here's where we disagree. As you say, negative tm_isdst means DST information is "not available"; however, there is nothing in the normative text that says how mktime() must behave when it is told that DST information is not available. The footnote is what does that, but it's non-normative.

(0006039) hvd (reporter) 2022-11-09 00:01	> however, there is nothing in the normative text that says how mktime() must behave when it is told that DST information is not available. We know that on a successful return of mktime(), "the other components are set to represent the specified calendar time". These other components again include tm_isdst, which thus must be set according to the description quoted earlier. If the implementation knows that Daylight Saving Time is in effect for the specified date and time, it must set tm_isdst to a positive value. If the implementation knows that Daylight Savings Time is not in effect for the specified date and time, it must set tm_isdst to zero. It's one thing to think that this isn't clear from the C standard. It's quite another when it has specifically been stated by the C standard committee that this is how the normative text is meant to be read to argue that it doesn't say that. It doesn't matter whether you're right that it doesn't say that: we have zero doubt about the intent, so even if you can convince the committee that they're wrong, we know the outcome would just be to clear up the wording. We save ourselves a whole lot of time by just treating it as settled now.

(0006042) geoffclare (manager) 2022-11-09 17:07	Re Note: 0006039 > If the implementation knows that Daylight Saving Time is in effect for the > specified date and time, it must set tm_isdst to a positive value. If the > implementation knows that Daylight Saving Time is not in effect for the > specified date and time, it must set tm_isdst to zero. Where is the normative text that says that? I can see nothing in C99 that forbids mktime(), or localtime() for that matter, returning a negative tm_isdst because "the information is not available".

(0006043) hvd (reporter) 2022-11-09 17:40	> Where is the normative text that says that? I can see nothing in C99 that forbids mktime(), or localtime() for that matter, returning a negative tm_isdst because "the information is not available". When we're talking about the cases where that information is available to the implementation, it's right there, "the information is not available" does not apply to that case. Of course, in situations where that information truly is unavailable, a negative tm_isdst could be appropriate, and that is consistent with the footnote and with the POSIX wording, as "attempt to determine" allows for the possibility that the determination fails.

(0006044) kre (reporter) 2022-11-09 21:15	Re Note: 0006042 and Note: 0006043 You're right, in C99 it is possible for tm_isdst to be returned with the value -1, if the implementation has no information on whether summer time applies or not. But here we tend to (also) live in a POSIX conforming environment, and then this issue cannot arise. A conforming POSIX environment always has some known timezone information, and always knows if summer time ever applies, and if it does apply, always knows when the transitions occur. Those are requirements to be conforming. Any time_t value (which represents a year which will fit into the tm_year field of a struct tm) will always be able to be converted to a struct_tm with tm_isdst ==0 or tm_isdst == 1 -- -1 as a return value cannot happen.

(0006045) hvd (reporter) 2022-11-09 23:18	> But here we tend to (also) live in a POSIX conforming environment, and then > this issue cannot arise. I was referring to the edge cases this issue is about there, the edge cases for which you have been arguing the most reasonable behaviour is for mktime() to return -1, but other implementations do return valid positive time_t values. I did not want to rule out the possibility of implementations setting tm_isdst to a negative value in those cases. We are in agreement that it should not happen in the normal cases.

(0006046) kre (reporter) 2022-11-10 10:19	Re Note: 0006045 No, that possibility is already ruled out. The "missing paragraph" from C99 that didn't make it into the POSIX spec of mktime() makes it quite clear that that cannot happen - the struct tm returned from a successful call of mktime() is required to be identical to a struct tm that would be returned by a call of localtime() on the result of mktime (and also, a second call of mktime() using the struct tm returned from the first must not alter the struct tm, and must return the same result. Since localtime() can (in POSIX) never return with tm_isdst == -1 mktime() cannot either.

(0006047) kre (reporter) 2022-11-10 10:28	Further re Note: 0006045 Also, if we were in a situation where we don't know whether or not summer time applies (or perhaps when it applies) in a particular timezone (somehow) then the "edge cases for which I have been arguing..." cannot occur either. If we don't know that summer time will commence (or end), or we don't know when that will happen, then we cannot possibly determine that a time is in the gap or foldback.

Issue History
Date Modified	Username	Field	Change
2022-11-03 13:36	kre	New Issue
2022-11-03 13:36	kre	Name	=> Robert Elz
2022-11-03 13:36	kre	Section	=> XSH 3/mktime
2022-11-03 13:36	kre	Page Number	=> 1331
2022-11-03 13:36	kre	Line Number	=> 44331-44332
2022-11-03 16:54	geoffclare	Note Added: 0006022
2022-11-03 18:04	hvd	Note Added: 0006025
2022-11-03 20:02	kre	Note Added: 0006028
2022-11-03 20:27	kre	Note Added: 0006030
2022-11-03 20:43	kre	Note Edited: 0006028
2022-11-03 20:48	kre	Note Edited: 0006028
2022-11-04 09:36	geoffclare	Note Added: 0006031
2022-11-04 10:01	geoffclare	Note Edited: 0006031
2022-11-04 17:37	kre	Note Added: 0006032
2022-11-04 17:43	kre	Note Edited: 0006032
2022-11-04 23:23	hvd	Note Added: 0006033
2022-11-04 23:23	hvd	Note Edited: 0006033
2022-11-07 12:33	geoffclare	Note Added: 0006034
2022-11-07 12:42	geoffclare	Note Added: 0006035
2022-11-07 12:59	hvd	Note Added: 0006036
2022-11-08 15:24	geoffclare	Note Added: 0006037
2022-11-09 00:01	hvd	Note Added: 0006039
2022-11-09 17:07	geoffclare	Note Added: 0006042
2022-11-09 17:40	hvd	Note Added: 0006043
2022-11-09 21:15	kre	Note Added: 0006044
2022-11-09 23:18	hvd	Note Added: 0006045
2022-11-10 10:19	kre	Note Added: 0006046
2022-11-10 10:28	kre	Note Added: 0006047

Relationships

Aardvark Mark IV