Date: Mon, 28 Nov 2022 09:35:25 +0000 From: "Geoff Clare via austin-group-l at The Open Group" <austin-group-l@opengroup.org> Message-ID: <Y4SA3TuYPU5CzdTx@localhost>
| When the standard is silent about something, requirements that | *are* stated still apply. Sure, but only for requirements that are actually stated. Here the things you believe to be stated requirements, don't seem to be nearly as obvious to me ... but it is hard to tell, as you almost never bother quoting the words from the standard that you claim say what you believe to be stated. That makes it hard to refute, as I have no idea what I am expected to argue is different - just some random "the standard says" without any clue what part of it you mean. So, from here on out, unless you actually quote the words that you're relying upon, I am going to ignore your arguments, and ask that everyone else take them with a grain of salt as well. | In this case, it is clear from the use of "any" in "corrected for | timezone and any seasonal time adjustments" that either a seasonal | adjustment is made or the value resulting from the timezone adjustment | is used without making a seasonal adjustment. This is better - we know which words you're relying upon here, and how you have managed to mangle what the standard actually says to fit with your preconceived view of what it should mean. The text you quoted there is from (in Issue 8 D 2.1) on page 1311, lines 43862 to 43863 (in XSH 3 / mktime()). (The same thing is in earlier versions, this just happens to be the version I picked to reference today, perhaps I should have used C181, but too late now...) Now lets analyse what that actually says: "corrected for timezone" which you ignored, but seem to be treating as if it said "modified by the offset from UTC of the timezone", which it does not, if it had meant to say that it could have said that. The only (not very good) definition of "timezone" I can find is in XBD 8.3 where it specifies TZ, which says TZ This variable shall represent timezone information. (page 161, line 5613 ... all references in this message will be to I8 D2.1) and then later says (lines 5621-3 same page) If TZ is of the first format (that is, if the first character is a <colon>), the characters following the <colon> are handled in an implementation-defined manner. So the definition of a timezone can be implementation defined - that is, everything about it, can be implementation defined, as the standard doesn't seem to specify anything (which is not really a surprise, as the POSIX has no particular influence over lawmakers who get to define how time works within their jurisdiction - but POSIX systems need to be able to work, and show some semblance of what is considered to be the correct local time, whatever those lawmakers deem to be appropriate). OK, next from your quote: "and any seasonal time adjustments" which you then paraphrased as: "either a seasonal adjustment is made or the value resulting from the timezone adjustment is used without making a seasonal adjustment." Don't you see just how myopic that is? In your mindset, you see a nice regular timezone which has a nice fixed offset from UTC, and perhaps at some point a once a year alteration of that offset slightly, and then, also once a year, an adjustment back again. Isn't it clear, even to you, that the "any...adjustments" is plural, and you made it singular "a seasonal adjustment" in your variant of what it says. There is no specification anywhere about how many seasonal adjustments there might be, or what those might look like. That they might not be able to be represented in a traditional (pre issue 8) TZ variable using non implementation defined syntax means nothing. Note that the timezone (when specified with the ':' syntax for TZ, and also in the newer syntax being added in I8) is never "undefined" or "unspecified" - just implementation defined. mktime() isn't excused from working with an implementation defined timezone specification, it needs to work with those as well, and such a thing does not necessarily have the nice neat form that you're expecting timezones to be like - and that the majority of the world's timezones (today) are nice and neat is irrelevant. (Think to systems using solar time for the local time, where the local time is set based upon sunrise each day - POSIX needs to work in that kind of environment as well, even if there might be none of those left, right now). You go on to claim: For times in the gap, the standard does not say which of these choices to make, so it is unspecified whether a seasonal adjustment is made or not, but those are the only two allowed behaviours. which I hope that you, and everyone else now, can see is absurd. There is not "a seasonal adjustment" that can be applied or not, there are many possible implementation defined adjustments that could be applied, and no specification of which should be, or what applying any particular seasonal adjustment might mean. But beyond that, there's this buried (unjustified) assumption in what you write, that a "time in the gap" is somehow a meaningful thing. It isn't, it doesn't exist at all, and one cannot make any assumptions about what it might mean if it did exist. To go back (this time with slightly more detail) to an earlier example I asked about, and you simply ignored. Let's say that someone sets out a list of the (broad) eye colours possible in any living creature, black, brown, green, blue, red (perhaps), hazel, ... (add as many here as you like). Now do you claim that the Loch Ness Monster's eyes must necessarily be one of those colours? Not "probably" or "perhaps" but "must be". How can one reason about anything which does not exist (again, and this is perhaps where some might claim my example is not quite on point, but for current purposes it doesn't matter) not just something which might exist but is unproven - but which is proven to not exist. Such a thing has no characteristics at all, that's what not existing means. Times in the gap do not exist. Period. One cannot apply rules or assumptions to them in any meaningful way - and certainly if one wanted to try, the language required to do so would need to be particularly explicit, and not just a misinterpreted "any" (as if that meant "if then else", which it never does, anywhere) pulled from the middle of a sentence. Before I end, there's one more section from the standard that you seem to be (not in this message, but in others) to be misinterpreting as well: Lines 43855 to 43858, page 1311, in XSH 3 - mktime(): A positive or 0 value for tm_isdst shall cause mktime( ) to presume initially that Daylight Saving Time, respectively, is or is not in effect for the specified time. A negative value for tm_isdst shall cause mktime( ) to attempt to determine whether Daylight Saving Time is in effect for the specified time. There are two issues here, one from each of those two sentences. First, you seem (in several earlier messages) seem to be under the impression that the standard requires that if tm_isdst is 0, then the answer from mktime() is required to be using the standard time offset. That is not what it says, if we leave out the alternative part for a minute (tm_isdst > 0) what that sentence says about tm_isdst == 0 is: A 0 value for tm_isdst shall cause mktime( ) to presume initially that Daylight Saving Time is not in effect for the specified time. (the >0 case is just the same, but with "not" removed). Note "presume initially". Like any presumption about anything, if the presumption is wrong, we abandon it. That certainly is not saying that setting tm_isdst to 0 requires the implementation to convert the broken down time as if summer time never existed in the zone, is it? No-one could claim that with any kind of credibility. What that means is that if we set tm_isdst == 0, and then specify a time which is in the summer time period, nothing at all in that specification (or anywhere else) requires the implementation to adjust the time in such a way as to alter the time specified explicitly by the code (the mktime() has no way to know how the values passed to it were calculated, or why, or the intent of that code's author) - it is perfectly reasonable that if the initial assumption is proven incorrect, to simply ignore it and take no other action at all. Second sentence: "to attempt to determine" An attempt is something that we are acknowledging might fail. If it meant "shall determine" (which is how you often seem to interpret this) it would have said that (and be absurd, as it is not always possible). There is no specification there (or anywhere) as to what happens when that attempt fails, and as shown above, there are not just two specified possible results (the standard nowhere says anything remotely like that) so again here, if the attempt fails, the results are unspecified and the implementation can produce any result it likes - including an error. kre