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
