View Issue Details

Jump to NotesJump to History
IDProjectCategoryView StatusDate SubmittedLast Update
0001613Issue 8 draftsSystem Interfacespublic2022-11-03 12:532024-06-11 09:12
Reporterkre Assigned To 
PrioritynormalSeverityObjectionTypeOmission
Status ClosedResolutionAccepted As Marked 
Product VersionDraft 2.1 
NameRobert Elz
Organization
User Reference
SectionXSH 3/mktime
Page Number1311
Line Number43850-43854, 43865-43866, 43867-43870
Final Accepted Text0001613:0006049
Summary0001613: XSH 3/mktime was not updated by the resolution of bug 1533, but should have been (++)
DescriptionNote while submitted against I8 D2.1 this should really have been
filed against D2.2 or D3 (whichever is to appear next) as it relates
to the resolution of bug 1533, which did not appear in D2.1

So... D2.1 it is.

The specification of mktime() says (lines 43850-4)

    The mktime( ) function shall convert the broken-down time, expressed as
    local time, in the structure pointed to by timeptr, into a time since the
    Epoch value with the same encoding as that of the values returned by
    time( ). The original values of the tm_wday and tm_yday components of
    the structure shall be ignored, and the original values of the other
    components shall not be restricted to the ranges described in <time.h>.

That is, it specifies which fields of struct tm (as defined in <time.h> and
the XBD page that defines it, are to be used, by simply (more or less) saying
"all except tm_yday and tm_wday".

That was OK (if a little lazy) before bug 1533 was applied, but is no longer
as now struct tm has two additional members (tm_gmtoff and tm_zone) which
should also be ignored by mktime().

That bug does not specify any changes to XSH 3/mktime to correct this.
Desired ActionChange lines 43850-43854 from the text given above in the description
to something like:

    The mktime( ) function shall convert the broken-down time, expressed as
    local time, in some fields of the structure pointed to by timeptr, into
    a time since the Epoch value with the same encoding as that of the values
    returned by time( ).

    The mktime( ) function shall make reference only the tm_year, tm_mon,
    tm_mday, tm_hour, tm_min, tm_sec, and tm_isdst components of the
    structure pointer to by timeptr, which values shall not be restricted
    to the ranges described in <time.h>.


Also, change in lines in 43865-43866 the text

    calculated from the other tm structure members specified in <time.h>
    (excluding tm_wday).

to say instead

    calculated from the components of the tm structure specified above,

Also change lines 43867-43870 from

    Upon successful completion, the values of the tm_wday and tm_yday
    components of the structure shall be set appropriately, and the other
    components shall be set to represent the specified time since the Epoch,
    but with their values forced to the ranges indicated in the <time.h>
    entry; the final value of tm_mday shall not be set until tm_mon and
    tm_year are determined.

into (something like)

    Upon successful completion, the components of the structure pointed
    to by timeptr specified above shall be set to represent the resulting
    time since the Epoch, but with their values forced to the ranges
    indicated in the <time.h> entry; the final value of tm_mday shall not
    be set until tm_mon and tm_year are determined. Other components of
    the structure shall be set to appropriate values to represent that
    time since the Epoch.

Tagsissue8

Activities

steffen

2022-11-03 17:56

reporter   bugnote:0006023

I thought it is redundant since mktime says clearly

  Local timezone information shall be set as though mktime( ) called tzset( )

Which implies that the mentioned fields cannot have a meaning in this regard?

P.S.: regarding the NetBSD ML thread on mktime(3), i did not send the letter

I have not followed this thread really, but just to note that
POSIX says "Local timezone information shall be set as though
mktime( ) called tzset( )."
"In such cases" (i do have no business here, mind you) i look at
musl. I _think_ the thread started due to that however...
But wanted to note that POSIX added no wording for mktime(3) with
the addition of gmtoff etc. musl does

  long long t = __tm_to_secs(tm);

^ Plain arithmetic that ignores timezone.

  __secs_to_zone(t, 1, &new.tm_isdst, &new.__tm_gmtoff, &opp, &new.__tm_zone);

^ "Sets zone" (1).

  if (tm->tm_isdst>=0 && new.tm_isdst!=tm->tm_isdst)
          t -= opp - new.__tm_gmtoff;

  t -= new.__tm_gmtoff;
  if ((time_t)t != t) goto error;

  __secs_to_zone(t, 0, &new.tm_isdst, &new.__tm_gmtoff, &opp, &new.__tm_zone);

^ Does not (0).

  if (__secs_to_tm(t + new.__tm_gmtoff, &new) < 0) goto error;

  *tm = new;
  return t;

kre

2022-11-03 20:21

reporter   bugnote:0006029

Re 0001613:0006023

Steffen, just ignore the NetBSD mailing list thread, that's just a couple of
people (one really) who have no idea at all what they're talking about and
are proposing utter nonsense which will never happen. That's gibberish.

I know the line you quoted from the standard (which is in both mktime() and
strftime()) about calling tzset (that applies to the NetBSD list discussion -
though the people there don't care what POSIX specifies, just that those
functions do what they are presuming that they should always do ... I intend
to post one last time there, soon, if things have finally calmed dowm and
both include that line from the standard, and show the fringe that NetBSD
already has (non-POSIX) interfaces that do exactly what they want, which
are in our manual pages, which they are obviously not bothering to read, but
while things are running hot, that would not go down well).

You may be correct that musl's broken (non-conforming) implementation here
may have been what triggered that discussion originally, but isn't what
added the heat. I don't think discussing implementation code details is
really appropriate here however.
 

But that line doesn't impact this current issue - there's no question but
that mktime() (and strftime) are required to treat the time as local time,
but local time can have more than one tm_gmtoff (and does, in any zone when
summer time applies) - and an implementation could use tm_gmtoff to help
it select which of the ambiguous time values in the "end of summer time,
time runs twice" situation.

My point here is that implementations must not do that, as doing so can
cause existing conforming applications to produce undefined behaviour.

While I am here, I see a line in the "Desired action" where I managed to make
two typos... (but neither of the form a spell checker can detect).

The line:
    structure pointer to by timeptr, which values shall not be restricted
should have said
    structure pointed to by timeptr, in which values shall not be restricted

Regular users are able to edit their own notes, like this one, but not the
problem description, nor desired action, so ...

geoffclare

2022-11-10 17:02

manager   bugnote:0006049

Last edited: 2022-11-10 17:05

 Change lines 43850-43854 from:
The mktime() function shall convert the broken-down time, expressed as local time, in the structure pointed to by timeptr, into a time since the Epoch value with the same encoding as that of the values returned by time(). The original values of the tm_wday and tm_yday components of the structure shall be ignored, and the original values of the other components shall not be restricted to the ranges described in <time.h>.
to:
The mktime() function shall convert the broken-down time, expressed as local time, in some members of the structure pointed to by timeptr, into a time since the Epoch value with the same encoding as that of the values returned by time( ). The mktime() function shall make use of only the tm_year, tm_mon, tm_mday, tm_hour, tm_min, tm_sec, and tm_isdst members of the structure pointed to by timeptr; the values of these members shall not be restricted to the ranges described in <time.h>.

Also, change in lines in 43865-43866 the text:
calculated from the other tm structure members specified in <time.h> (excluding tm_wday).
to:
calculated from the members of the tm structure specified above.

Also change lines 43867-43870 from:
Upon successful completion, the values of the tm_wday and tm_yday components of the structure shall be set appropriately, and the other components shall be set to represent the specified time since the Epoch, but with their values forced to the ranges indicated in the <time.h> entry; the final value of tm_mday shall not be set until tm_mon and tm_year are determined.
to:
[CX]Upon successful completion, the members of the structure shall be set to the values that would be returned by a call to localtime() with the specified time since the Epoch as its argument.[/CX]

Issue History

Date Modified Username Field Change
2022-11-03 12:53 kre New Issue
2022-11-03 12:53 kre Name => Robert Elz
2022-11-03 12:53 kre Section => XSH 3/mktime
2022-11-03 12:53 kre Page Number => 1311
2022-11-03 12:53 kre Line Number => 43850-43854, 43865-43866, 43867-43870
2022-11-03 17:56 steffen Note Added: 0006023
2022-11-03 20:21 kre Note Added: 0006029
2022-11-10 17:02 geoffclare Note Added: 0006049
2022-11-10 17:03 geoffclare Final Accepted Text => 0001613:0006049
2022-11-10 17:03 geoffclare Status New => Resolved
2022-11-10 17:03 geoffclare Resolution Open => Accepted As Marked
2022-11-10 17:03 geoffclare Tag Attached: issue8
2022-11-10 17:05 geoffclare Note Edited: 0006049
2022-11-30 16:50 geoffclare Status Resolved => Applied
2024-06-11 09:12 agadmin Status Applied => Closed