Robert Elz wrote, on 04 Dec 2022:
>
> 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>
>
This entire email is underhanded and dishonest. You have completely
ignored my earlier email (austin-group-l:archive/latest/35115) where
I stated that for TZ values beginning with a colon, the timezone
information used by mktime() is implementation-defined and therefore
this creates the same loophole that exists in the C standard, and
then you have tried to refute the arguments I made, which were (with
that earlier email as context) intended only to apply to TZ values not
beginning with colon as if I was saying them about TZ values that do
begin with a colon.
As a result, most of it made no sense at all in context, and I have
only replied to the parts that could have made some sort of sense in
the context of TZ values that do not begin with a colon.
> | 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.
This has been a lengthy thread and I have been assuming that if I
quoted something from the standard earlier in the thread I don't need
to quote it again.
> | 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.
It has to be worded in general terms because of the implementation-defined
nature of TZ values beginning with colon. For TZ values that do not
begin with colon, the description of TZ in XBD 8.3 gives precise rules
for the adjustments:
std offset dst offset, rule
[...]
offset
Indicates the value added to the local time to arrive at
Coordinated Universal Time
[...]
The offset following std shall be required. If no offset
follows dst, the alternative time is assumed to be one hour
ahead of standard time.
[...]
rule
Indicates when to change to and back from the alternative time.
> 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.
Exactly as specified in the TZ rules for values not beginning with colon.
> 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.
This wording is taken from the C standard, where it is necessarily vague
because of the implementation-defined nature of local time and DST there.
We should replace it with more precise wording in POSIX (particularly for
TZ values not beginning with colon).
--
Geoff Clare <g.cl...@opengroup.org>
The Open Group, Apex Plaza, Forbury Road, Reading, RG1 1AX, England
