The following issue has a resolution that has been APPLIED.
==
https://austingroupbugs.net/view.php?id=1614
==
Reported By:kre
Assigned To:
The following issue has been UPDATED.
==
https://austingroupbugs.net/view.php?id=1614
==
Reported By:kre
Assigned To:
The following issue has been UPDATED.
==
https://austingroupbugs.net/view.php?id=1614
==
Reported By:kre
Assigned To:
The following issue NEEDS AN INTERPRETATION.
==
https://www.austingroupbugs.net/view.php?id=1614
==
Reported By:kre
Assigned To:
The following issue has been set as RELATED TO issue 0001627.
==
https://austingroupbugs.net/view.php?id=1614
==
Reported By:kre
Assigned
A NOTE has been added to this issue.
==
https://austingroupbugs.net/view.php?id=1614
==
Reported By:kre
Assigned To:
Robert Elz wrote, on 20 Dec 2022:
>
> Date:Fri, 16 Dec 2022 17:31:03 +
> From:"Geoff Clare via austin-group-l at The Open Group"
>
>
> | (Note that I was careful to say
> | "system" not "implementation" - Paul Eggert's C defect report said
> | that the Arthur
Date:Fri, 16 Dec 2022 17:31:03 +
From:"Geoff Clare via austin-group-l at The Open Group"
Message-ID:
| Before I get into detailed responses, please note this is my last
| working day before the holiday break, so I won't be contributing to
| this
Robert Elz wrote, on 14 Dec 2022:
>
> Date:Tue, 13 Dec 2022 16:52:42 +
> From:"Geoff Clare via austin-group-l at The Open Group"
>
>
Before I get into detailed responses, please note this is my last
working day before the holiday break, so I won't be contributing to
Date:Wed, 14 Dec 2022 08:08:36 +0700
From:"Robert Elz via austin-group-l at The Open Group"
Message-ID: <11981.1670980...@jacaranda.noi.kre.to>
| Set the input to represent Jan 1, 2023, noon. (Jan 1 just so
| working out yday is simple)
Which turns out to
Date:Tue, 13 Dec 2022 16:52:42 +
From:"Geoff Clare via austin-group-l at The Open Group"
Message-ID:
| No, the adjustment to bring struct tm fields into range is done after
| the time since the Epoch value has been calculated.
Just in case you don't
Date:Tue, 13 Dec 2022 16:52:42 +
From:"Geoff Clare via austin-group-l at The Open Group"
Message-ID:
| It is too late to add timegm() in Issue 8.
I suspected that would be the case. Pity, as using UTC (or
whatever it is that POSIX time is really called,
Robert Elz wrote, on 12 Dec 2022:
>
> Date:Mon, 12 Dec 2022 12:02:39 +
> From:"Geoff Clare via austin-group-l at The Open Group"
>
>
> C23 is apparently going to have timegm() (the mktime() equivalent for UTC
> instead of localtime). Using gmtime() modifying the
Date:Mon, 12 Dec 2022 12:02:39 +
From:"Geoff Clare via austin-group-l at The Open Group"
Message-ID:
| The above misrepresents my claims in a few respects.
|
| "the POSIX standard precludes an implementation from returning an error"
|
| I only claim
Robert Elz wrote, on 12 Dec 2022:
>
> Date:Thu, 8 Dec 2022 11:22:04 -0800
> From:"Don Cragun via austin-group-l at The Open Group"
>
>
> | I agree with Geoff.
>
> I actually don't think you do, not really. You might not agree with
> me, or not now, but your argument
Date:Thu, 8 Dec 2022 11:22:04 -0800
From:"Don Cragun via austin-group-l at The Open Group"
Message-ID: <7fd37609-74ff-42f5-a974-76c7010ee...@sonic.net>
| I agree with Geoff.
I actually don't think you do, not really. You might not agree with
me, or not now, but
Robert & Geoff have been arguing about whether or not giving a struct tm to
mktime() that specifies a time in the gap between standard time and daylight
time is allowed to be treated as an error (assuming that the seconds since the
Epoch would otherwise fit in a time_t).
Robert is arguing that
Robert Elz wrote, on 06 Dec 2022:
>
> Date:Tue, 6 Dec 2022 12:01:52 +
> From:"Geoff Clare via austin-group-l at The Open Group"
>
>
> | You have completely
> | ignored my earlier email (austin-group-l:archive/latest/35115) where
> | I stated that for TZ values
Date:Tue, 6 Dec 2022 12:01:52 +
From:"Geoff Clare via austin-group-l at The Open Group"
Message-ID:
| 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
Robert Elz wrote, on 04 Dec 2022:
>
> Date:Mon, 28 Nov 2022 09:35:25 +
> From:"Geoff Clare via austin-group-l at The Open Group"
>
>
This entire email is underhanded and dishonest. You have completely
ignored my earlier email (austin-group-l:archive/latest/35115)
Date:Mon, 28 Nov 2022 09:35:25 +
From:"Geoff Clare via austin-group-l at The Open Group"
Message-ID:
| When the standard is silent about something, requirements that
| *are* stated still apply.
Sure, but only for requirements that are actually stated.
Robert Elz wrote, on 25 Nov 2022:
>
> Date:Thu, 24 Nov 2022 15:49:49 +
> From:"Geoff Clare via austin-group-l at The Open Group"
>
>
> | Combining the above with the TZ rules, if TZ=EST5EDT then POSIX requires
> | that mktime() calculates seconds since the Epoch
Date:Fri, 25 Nov 2022 13:17:36 +
From:Harald van Dijk
Message-ID:
| Does POSIX actually specify the seasonal
| adjustment, if applied, has to be 1 hour?
No, it doesn't - that's just the default (as it is most common) if an
(old style) POSIX TZ string
On 25/11/2022 05:40, Robert Elz via austin-group-l at The Open Group wrote:
Date:Thu, 24 Nov 2022 15:49:49 +
From:"Geoff Clare via austin-group-l at The Open Group"
Message-ID:
| Combining the above with the TZ rules, if TZ=EST5EDT then POSIX requires
Date:Thu, 24 Nov 2022 15:49:49 +
From:"Geoff Clare via austin-group-l at The Open Group"
Message-ID:
| Combining the above with the TZ rules, if TZ=EST5EDT then POSIX requires
| that mktime() calculates seconds since the Epoch as specified in XBD 4.16
|
Robert Elz wrote, on 24 Nov 2022:
>
> Date:Tue, 22 Nov 2022 12:49:13 +
> From:"Geoff Clare via austin-group-l at The Open Group"
>
>
> | Having returned refreshed from my break, I have re-examined this issue
> | and I now have a clear understanding of why the C
Date:Tue, 22 Nov 2022 12:49:13 +
From:"Geoff Clare via austin-group-l at The Open Group"
Message-ID:
| 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
Date:Tue, 22 Nov 2022 12:49:13 +
From:"Geoff Clare via austin-group-l at The Open Group"
Message-ID:
| Because when the change happened, 1981-12-31 23:30:00 in the old time
| zone became 1982-01-01 00:00:00 in the new timezone.
That's now been confirmed
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.
Previously I had been fixated on the tm_isdst text that is a
non-normative footnote in C but
Date:Thu, 10 Nov 2022 12:33:47 +
From:"Geoff Clare via austin-group-l at The Open Group"
Message-ID:
| You are the one requesting a radical change to the standard.
Actually, I am not. That's why I am trying to get you to explain
where the standard says
Geoff Clare wrote, on 10 Nov 2022:
>
> I agree that it would worthwhile to clarify this in POSIX. Perhaps we
> should change:
>
> Upon successful completion, the values of the tm_wday and tm_yday
> components of the structure shall be set appropriately, and the
> other components
Robert Elz wrote, on 09 Nov 2022:
>
> From:"Geoff Clare via austin-group-l at The Open Group"
>
>
> | We are going round in circles. You already asked that (probably in
> | different words) and I already answered it.
>
> Which implies that your answer did not convince me.
A NOTE has been added to this issue.
==
https://austingroupbugs.net/view.php?id=1614
==
Reported By:kre
Assigned To:
A NOTE has been added to this issue.
==
https://austingroupbugs.net/view.php?id=1614
==
Reported By:kre
Assigned To:
A NOTE has been added to this issue.
==
https://austingroupbugs.net/view.php?id=1614
==
Reported By:kre
Assigned To:
A NOTE has been added to this issue.
==
https://austingroupbugs.net/view.php?id=1614
==
Reported By:kre
Assigned To:
A NOTE has been added to this issue.
==
https://austingroupbugs.net/view.php?id=1614
==
Reported By:kre
Assigned To:
A NOTE has been added to this issue.
==
https://austingroupbugs.net/view.php?id=1614
==
Reported By:kre
Assigned To:
A NOTE has been added to this issue.
==
https://austingroupbugs.net/view.php?id=1614
==
Reported By:kre
Assigned To:
Date:Tue, 8 Nov 2022 18:15:20 +
From:"Geoff Clare via austin-group-l at The Open Group"
Message-ID:
| We are going round in circles. You already asked that (probably in
| different words) and I already answered it.
Which implies that your answer did not
Robert Elz wrote, on 08 Nov 2022:
>
> | It should behave the same as for tm_isdst=0 or for tm_isdst=1, whichever
> | it deems the most appropriate.
>
> And if it decides that it is not its job to make that decision?
> What would be its basis for choice, and why? And where in the
> standard
Date:Tue, 8 Nov 2022 15:24:21 +
From:Austin Group Bug Tracker
Message-ID: <60fe2d9d8f9a9039da59e45877c42...@austingroupbugs.net>
| Here's where we disagree. As you say, negative tm_isdst means DST
| information is "not available"; however, there is nothing
A NOTE has been added to this issue.
==
https://austingroupbugs.net/view.php?id=1614
==
Reported By:kre
Assigned To:
[Forwarded on the request of kre.]
Date:Mon, 7 Nov 2022 12:31:33 +
From:"Geoff Clare via austin-group-l at The Open Group"
Message-ID:
| It should behave the same as for tm_isdst=0 or for tm_isdst=1, whichever
| it deems the most appropriate.
And if it
Date:Mon, 7 Nov 2022 12:31:33 +
From:"Geoff Clare via austin-group-l at The Open Group"
Message-ID:
I sent a long reply to Geoff (forgot to add a cc to the list) which
I am hoping he will eventually forward here.
One of the topic covered came from this:
|
A NOTE has been added to this issue.
==
https://austingroupbugs.net/view.php?id=1614
==
Reported By:kre
Assigned To:
A NOTE has been added to this issue.
==
https://austingroupbugs.net/view.php?id=1614
==
Reported By:kre
Assigned To:
A NOTE has been added to this issue.
==
https://austingroupbugs.net/view.php?id=1614
==
Reported By:kre
Assigned To:
> --
> (0006032) kre (reporter) - 2022-11-04 17:37
> https://austingroupbugs.net/view.php?id=1614#c6032
> --
> Re
Garrett Wollman wrote, on 04 Nov 2022:
>
> < austin-group-l at The Open Group" said:
>
> > 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
A NOTE has been added to this issue.
==
https://austingroupbugs.net/view.php?id=1614
==
Reported By:kre
Assigned To:
A NOTE has been added to this issue.
==
https://austingroupbugs.net/view.php?id=1614
==
Reported By:kre
Assigned To:
< said:
> 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
A NOTE has been added to this issue.
==
https://austingroupbugs.net/view.php?id=1614
==
Reported By:kre
Assigned To:
A NOTE has been added to this issue.
==
https://austingroupbugs.net/view.php?id=1614
==
Reported By:kre
Assigned To:
A NOTE has been added to this issue.
==
https://austingroupbugs.net/view.php?id=1614
==
Reported By:kre
Assigned To:
A NOTE has been added to this issue.
==
https://austingroupbugs.net/view.php?id=1614
==
Reported By:kre
Assigned To:
A NOTE has been added to this issue.
==
https://austingroupbugs.net/view.php?id=1614
==
Reported By:kre
Assigned To:
The following issue has been SUBMITTED.
==
https://austingroupbugs.net/view.php?id=1614
==
Reported By:kre
Assigned To:
59 matches
Mail list logo
