Re: [musl] Broken mktime calculations when crossing DST boundary

[Alexander Weps <exander77@pm.me>]

[-- Attachment #1: Type: text/plain, Size: 6836 bytes --]

Attaching whole:
Minutes of the 27th July 2023 Teleconference    Austin-1332 Page 1 of 1
Submitted by Andrew Josey, The Open Group.         28th July 2023

Also go through:
https://www.austingroupbugs.net/view.php?id=1614

Seems most of what We talk here was already addressed.

AW


On Wednesday, March 27th, 2024 at 01:14, Alexander Weps <exander77@pm.me> wrote:

> See below.
>
> AW
>
>
>
>
> On Tuesday, March 26th, 2024 at 22:59, Thorsten Glaser tg@mirbsd.de wrote:
>
> > Alexander Weps dixit:
> >
> > > > Not at all, glibc’s mktime just throws the towel with
> > > > EOVERFLOW saying that the requested time does not exist.
> > >
> > > How is this not compliant with POSIX?
> >
> > POSIX indicates that this is valid only if the date is not
> > representable in time_t, and it has different handling for
> > dates that fall into gaps, see the other mails from me, as
> > well as below.
>
>
> I think you confuse two things here:
>
> 1. mktime returning -1
> 2. mktime setting errno to EOVERFLOW
>
> The 2. maybe debatable in obscure circles, but that's entirely unrelated.
>
> But mktime can return -1 if and when it deems that struct tm cannot be represented in epoch seconds.
>
> That is entirely compliant with POSIX and I would need to see some hard evidence for it not being the case.
>
> From Issue 7:
>
> > RETURN VALUE
> >
> > The mktime() function shall return the specified time since the Epoch encoded as a value of type time_t. If the time since the Epoch cannot be represented, the function shall return the value (time_t)-1 [CX] [Option Start] and set errno to indicate the error. [Option End]
> >
> > ERRORS
> >
> > The mktime() function shall fail if:
> >
> > [EOVERFLOW]
> > [CX] [Option Start] The result cannot be represented. [Option End]
>
>
>
> First and foremost mktime may fail and when it fails it returns -1.
>
> Issue 6: If the time since the Epoch cannot be represented, the function shall return the value (time_t)-1 and may set errno to indicate the error.
> Isuse 7: If the time since the Epoch cannot be represented, the function shall return the value (time_t)-1 and set errno to indicate the error.
>
> Only errno offered is EOVERFLOW.
> So I interpret it that since Issue 7, the correct behavior is to set errno to EOVERFLOW.
>
> Also from:
> Minutes of the 27th July 2023 Teleconference Austin-1332 Page 1 of 1
> Submitted by Andrew Josey, The Open Group. 28th July 2023
>
> > Bug 1614: XSH 3/mktime does not specify EINVAL and should Accepted as Marked
> > https://austingroupbugs.net/view.php?id=1614
> >
> > An interpretation is required.
> >
> > Interpretation response:
> > The standard clearly states that when an unsuccessful call to
> > mktime() returns (time_t)-1 it sets errno to [EOVERFLOW], and
> > conforming implementations must conform to this.
> >
> > Rationale:
> >
> > The RETURN VALUE section on the mktime() page states:
> > If the time since the Epoch cannot be represented, the function
> > shall return the value (time_t)-1 [CX]and set errno to indicate
> > the error[/CX].
> >
> > This requires that errno is set to indicate "the error", and the
> > beginning of the sentence states the nature of the error condition
> > to which "the error" refers: the time since the Epoch (i.e. the
> > integer value to be returned) cannot be represented. The ERRORS
> > section requires that the error number [EOVERFLOW] is used for this
> > condition.
> >
> > Thus the standard requires that errno is set to [EOVERFLOW] when
> > an unsuccessful call to mktime() returns (time_t)-1 and an
> > implementation that sets it to [EINVAL] does not conform.
> >
> > The mktime() function does not have any way to indicate to the
> > caller that an error other than [EOVERFLOW] occurred.
>
> > > This is perfectly valid behavior, that is both expected and can be
> > > handled in code easily.
> >
> > No, it’s a bug in glibc.
> >
> > > I have to ask, but have you actually used mktime from the application end?
> >
> > Of course.
> >
> > > I am not sure what you mean by correct. Struct tm is neither correct
> > > nor incorrect. It can be in three states:
> > > 1) Set by user.
> > > 2) Normalized by mktime.
> > > 3) Not fully normalized by mktime.
> >
> > Huh? No.
>
>
> Then explain what is incorrect struct tm.
>
> > > If I get -1, I know the struct tm does not represent valid time_t and I
> > > handle it and move on.
> >
> > Define “move on”. With POSIX’ mktime interface, if you get -1 and
> > EOVERFLOW, then moving further into the same direction will never
> > give you not -1 again, because -1 is what you get when your tm_year
> > was too far out of the representation (e.g. 2039 on a system with
> > a 32-bit time_t).
>
>
> Not true as shown above.
>
> > EOVERFLOW means that the time cannot be represented in time_t, not
> > that the time cannot be represented in struct tm. And for these
> > gaps, the time_t values are consecutive (1325239199/1325239200).
>
>
> No, return value -1 means that the time cannot represented as epoch seconds (for any number of reasons).
>
> Required errno is Issue 7 change that should be used to indicate type of error, but only EOVERFLOW is listed.
>
> > > This is perfect example (TZ=Pacific/Apia):
> > >
> > > before: 2011-12-31 00:00:00 +14 0
> > > after1: 2011-12-31 00:00:00 +14 1325239200
> > > after1: 2011-12-30 00:00:00 +14 -1
> >
> > No, this cannot give -1 per POSIX.
>
>
> Not true as shown above.
>
> > > Musl instead of giving sane results starts running in the circle at some point:
> > > after2: 2011-12-29 00:00:00 -10 1325152800
> > > after3: 2011-12-29 00:00:00 -10 1325152800
> >
> > That’s because it does this correctly.
> >
> > > Doesn't work, this will not give the same time next day, this fails on
> > > STD/DST changes.
> > >
> > > Because same time next day is not always 86400 apart.
> >
> > I know. But the basic assumption that there even is such a
> > thing as “same time next day” made by you is invalid. POSIX
> > listed several examples (29ᵗʰ February next year as well as
> > gaps in timezone offsets).
> >
> > One thing you can do is to add 86400, localtime(), then check
> > that at least tm_mday, tm_hour and tm_min (Issue 8d4, line
> > 48052) are what you expect, and handle cases where they aren’t
> > manually. But having added 86400, you have two starting points
> > from which to manually approach this (the original value and
> > the newer value). (Perhaps a location could even skip more than
> > 24 hours in a discontinuity.)
> >
> > bye,
> > //mirabilos
> > --
> > “Having a smoking section in a restaurant is like having
> > a peeing section in a swimming pool.”
> > -- Edward Burr

[-- Attachment #2: austin_1332.txt --]
[-- Type: text/plain, Size: 12402 bytes --]

Minutes of the 27th July 2023 Teleconference    Austin-1332 Page 1 of 1
Submitted by Andrew Josey, The Open Group.         28th July 2023

Attendees:
    Andrew Josey, The Open Group 
    Don Cragun,  IEEE PASC OR
    Mark Ziegast, SHware Systems Dev.
    Geoff Clare, The Open Group
    Eric Ackermann, HPI, University of Potsdam
    Eric Blake, Red Hat, The Open Group OR

Apologies
    Nick Stoughton, Logitech/USENIX, ISO/IEC JTC 1/SC 22 OR 
    Tom Thompson, IEEE

* General news

The meeting on July 31 will be a webex.
The meeting logistics for August 3rd are undecided as to whether it
is a zoom or webex meeting. We will check with Nick on Monday.

Andrew noted that draft planning is still to be done. 
It is expected that the cutoff for the next draft will be determined
by the closing date for open interpretations.

* Current Business

Note for issue resolution all items are tagged for Issue 8 unless
noted otherwise or disposition is reject or duplicate.


Bug 1766: catgets: quotation in "Change History" lacks closing quotes Accepted
https://austingroupbugs.net/view.php?id=1766

This item is tagged for TC3-2008.

Bug 1769: CX shading needed for fputwc() EILSEQ error indicator requirement Accepted
https://austingroupbugs.net/view.php?id=1769


Bug 1614: XSH 3/mktime does not specify EINVAL and should  Accepted as Marked
https://austingroupbugs.net/view.php?id=1614

An interpretation is required.

Interpretation response:
The standard clearly states that when an unsuccessful call to
mktime() returns (time_t)-1 it sets errno to [EOVERFLOW], and
conforming implementations must conform to this.

Rationale:

The RETURN VALUE section on the mktime() page states:
    If the time since the Epoch cannot be represented, the function
    shall return the value (time_t)-1 [CX]and set errno to indicate
    the error[/CX].

This requires that errno is set to indicate "the error", and the
beginning of the sentence states the nature of the error condition
to which "the error" refers: the time since the Epoch (i.e. the
integer value to be returned) cannot be represented. The ERRORS
section requires that the error number [EOVERFLOW] is used for this
condition.

Thus the standard requires that errno is set to [EOVERFLOW] when
an unsuccessful call to mktime() returns (time_t)-1 and an
implementation that sets it to [EINVAL] does not conform.

The mktime() function does not have any way to indicate to the
caller that an error other than [EOVERFLOW] occurred.

Notes to the Editor (not part of this interpretation):
On page 425 line 14451 section <time.h>, after applying bug 1253 change:
    The value of tm_isdst shall be positive if Daylight Saving Time
    is in effect, 0 if Daylight Saving Time is not in effect, and
    negative if the information is not available.
to:
    When tm_isdst is set by an interface defined in this standard,
    its value shall be positive if Daylight Saving Time (DST) is
    in effect and 0 if DST is not in effect. [CX]It shall not be
    set to a negative value by any interface defined in this standard.
    When tm_isdst is passed to the mktime() function, it specifies
    how mktime() is to handle DST when calculating the time since
    the Epoch value; see [xref to mktime()].[/CX]

On page 1331 line 44310 section mktime(), delete:
    A positive or 0 value for tm_isdst shall cause mktime() to
    presume initially that Daylight Savings 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 Savings Time is in effect for the specified time.

On page 1331 line 44317 section mktime(), change:
    corrected for timezone and any seasonal time adjustments
to:
    corrected for the offset of the timezone's standard time from
    Coordinated Universal Time and further corrected (if applicable--see
    below) for Daylight Saving Time

After page 1331 line 44321 section mktime(), add these new paragraphs:
    [CX]If the timezone is one that includes Daylight Saving Time
    (DST) adjustments, the value of tm_isdst in the tm structure
    controls whether or not mktime() adjusts the calculated seconds
    since the Epoch value by the DST offset (after it has made the
    timezone adjustment), as follows:

	If tm_isdst is zero, mktime() shall not further adjust the
	seconds since the Epoch by the DST offset.

	If tm_isdst is positive, mktime() shall further adjust the
	seconds since the Epoch by the DST offset.

	If tm_isdst is negative, mktime() shall attempt to determine
	whether DST is in effect for the specified time; if it
	determines that DST is in effect it shall produce the same
	result as an equivalent call with a positive tm_isdst value,
	otherwise it shall produce the same result as an equivalent
	call with a tm_isdst value of zero. If the broken-down time
	specifies a time that is either skipped over or repeated
	when a transition to or from DST occurs, it is unspecified
	whether mktime() produces the same result as an equivalent
	call with a positive tm_isdst value or as an equivalent
	call with a tm_isdst value of zero.

    If the TZ environment variable specifies a geographical timezone
    for which the implementation's timezone database includes
    historical or future changes to the offset from Coordinated
    Universal Time of the timezone's standard time, and the broken-down
    time corresponds to a time that was (or will be) skipped over
    or repeated due to the occurrence of such a change, mktime()
    shall calculate the time since the Epoch value using either the
    offset in effect before the change or the offset in effect after
    the change.[/CX]

On page 1331 line 44323 section mktime(), after applying bug 1613 change:
    with the specified time since the Epoch as its argument
to:
    with the calculated time since the Epoch as its argument

On page 1331 line 44327 section mktime(), change:
    The mktime() function shall return the specified time since the
    Epoch encoded as a value of type time_t. If the time since the
    Epoch cannot be represented, the function shall return the value
    (time_t)-1 [CX]and set errno to indicate the error[/CX].
to:
    The mktime() function shall return the calculated time since
    the Epoch encoded as a value of type time_t. If the time since
    the Epoch cannot be represented as a time_t [CX]or the value
    to be returned in the tm_year member of the structure pointed
    to by timeptr cannot be represented as an int[/CX], the function
    shall return the value (time_t)-1 [CX]and set errno to [EOVERFLOW],
    and shall not change the value of the tm_wday component of the
    structure.[/CX]

    [CX]Since (time_t)-1 is a valid return value for a successful
    call to mktime(), an application wishing to check for error
    situations should set tm_wday to a value less than 0 or greater
    than 6 before calling mktime(). On return, if tm_wday has not
    changed an error has occurred.[/CX]

On page 1332 line 44348 section mktime(), change:
    if (mktime(&time_str) == -1)
to:
    time_str.tm_wday = -1;
    if (mktime(&time_str) == (time_t)-1 && time_str.tm_wday == -1)

On page 1332 line 44359 section mktime(), change RATIONALE from "None" to:
    In order to allow applications to distinguish between a successful
    return of (time_t)-1 and an [EOVERFLOW] error, mktime() is
    required not to change tm_wday on error. This mechanism is used
    rather than the convention used for other functions whereby the
    application sets errno to zero before the call and the call
    does not change errno on error because the ISO C standard does
    not require mktime() to set errno on error. The next revision
    of the ISO C standard is expected to require that mktime() does
    not change tm_wday when returning (time_t)-1 to indicate an
    error, and that this return convention is used both for the
    case where the value to be returned by the function cannot be
    represented as a time_t and the case where the value to be
    returned in the tm_year member of the tm structure cannot be
    represented as an int.

    The DESCRIPTION section says that mktime() converts the specified
    broken-down time into a time since the Epoch value. The use of
    the indefinite article here is necessary because, when tm_isdst
    is negative and the timezone has Daylight Saving Time transitions,
    there is not a one-to-one correspondence between broken-down
    times and time since the Epoch values.

    The description of how the value of tm_isdst affects the behavior
    of mktime() is shaded CX because the requirements in the ISO C
    standard are unclear. The next revision of the ISO C standard
    is expected to state the requirements using wording equivalent
    to the wording in this standard.

Bug 1647: printf("%lc", (wint_t)0) can't output NUL byte Accepted as Marked
https://austingroupbugs.net/view.php?id=1647

Now the C committee has responded to our feedback, we can approve
the proposed interpretation. (closed after meeting)


Bug 1768: catgets: incomplete paragraph in "Change History" Accepted as Marked
https://austingroupbugs.net/view.php?id=1768

This item is tagged for TC3-2008

The text of Austin Group Interpretation 1003.1-2001 #148 can be found here:

https://collaboration.opengroup.org/austin/interps/documents/14539/AI-148.txt [^]

It doesn't contain any changes to catgets().

We considered whether there might be a typo in the 148 number, but we
have been unable to find any other interpretation (besides #044
that is already listed) affecting catgets(), and as far as it can
be seen, all of the changes to catgets() between Issue 6 and Issue 7
are described in the other Change History entries.

The other possibility is that this entry should have been on a
different page, but all of the functions affected by #148 have a
Change History entry for it.

All we can do at this point is treat this line as spurious and delete it.


Bug 1770: Typo re iswblank_l Accepted
https://austingroupbugs.net/view.php?id=1770 

This item is tagged for TC3-2008

Bug 1767: sed: clarify behavior of c (change) command Accepted
https://austingroupbugs.net/view.php?id=1767

Bug 1747: mailx: document alias expansion prevention Accepted
https://austingroupbugs.net/view.php?id=1747

Bug 1746: fuser output format clarification
https://austingroupbugs.net/view.php?id=1746

This item is tagged for TC3-2008

An interpretation is required.

Interpretation response:
The standard states that the process ID is written using the format
"%d", and conforming implementations must conform to this. However,
concerns have been raised about this which are being referred to
the sponsor.

Rationale:
Format "%d" allows, but does not require a space or tab before the
process ID. The standard should require separation between process
IDs in order for the output to be usable.

Notes to the Editor (not part of this interpretation):

Make the changes in bugnote:6341

Bug 1745: tsort input and output format clarifications Accepted as Marked
https://austingroupbugs.net/view.php?id=1745

This item is tagged for TC3-2008.
An interpretation is required.

Interpretation response:
The standard is unclear on this issue, and no conformance distinction
can be made between alternative implementations based on this. This
is being referred to the sponsor.

Rationale:
None.

Notes to the Editor (not part of this interpretation):
Make the changes in the Desired Action.

We will continue next time on:

Bug 1732: cp and mv EXIT STATUS does not account for -i
https://austingroupbugs.net/view.php?id=1732

Next Steps
----------
The next call is on:

   Mon 2023-07-31 (Webex meeting - general bugs/ballot resolution)
   Thu 2023-08-03 (TBD Zoom or Webex meeting - general bugs/ballot resolution)

The calls are for 90 minutes

Calls are anchored on US time. (8am Pacific)

Please check the calendar invites for dial in details.

Apologies in advance:
    Tom Thompson 2023-07-31
    Andrew Josey 2023-08-07, 2023-08-10


Bugs are at:
https://austingroupbugs.net

An etherpad is usually up for the meeting, with a URL using the date format as below:

https://posix.rhansen.org/p/20xx-mm-dd

(For write access this uses The Open Group single sign on,
for those individuals with gitlab.opengroup.org accounts.
Please contact Andrew if you need to be setup)