[Bug time/31558] New: mktime wildly mishandles times near Pacific/Apia tz discontinuity

[Bug time/31558] New: mktime wildly mishandles times near Pacific/Apia tz discontinuity

[bugdal at aerifal dot cx]

https://sourceware.org/bugzilla/show_bug.cgi?id=31558

            Bug ID: 31558
           Summary: mktime wildly mishandles times near Pacific/Apia tz
                    discontinuity
           Product: glibc
           Version: unspecified
            Status: UNCONFIRMED
          Severity: normal
          Priority: P2
         Component: time
          Assignee: unassigned at sourceware dot org
          Reporter: bugdal at aerifal dot cx
  Target Milestone: ---

Given tm_year=2011-1900, tm_mon=12-1, tm_mday=31, all other fields 0, and
TZ=Pacific/Apia, glibc mktime produces an output of 2012-01-01 01:00:00 (time_t
1325329200), offset a whole day forward from what it should be. The affected
input is not even a time in the omitted day (2011-12-30 does not exist in this
zone) but 1 hour into the following day, which exists. The problem seems to be
related to how tm_isdst=0 is being applied - DST is active at this time - but
with or without it applied, the time never falls into the limbo day.

Discovered as part of a monster thread about the topic of this zone transition
on the musl libc mailing list.

-- 
You are receiving this mail because:
You are on the CC list for the bug.

[Bug time/31558] mktime wildly mishandles times near Pacific/Apia tz discontinuity

[schwab@linux-m68k.org]

https://sourceware.org/bugzilla/show_bug.cgi?id=31558

--- Comment #1 from Andreas Schwab <schwab@linux-m68k.org> ---
Pacific/Apia  Fri Dec 30 09:59:59 2011 UT = Thu Dec 29 23:59:59 2011 -10
isdst=1 gmtoff=-36000
Pacific/Apia  Fri Dec 30 10:00:00 2011 UT = Sat Dec 31 00:00:00 2011 +14
isdst=1 gmtoff=50400

When tm_isdst is nonzero, the correct output is produced.

localtime produces the same wrong output when called with 1325329200.

-- 
You are receiving this mail because:
You are on the CC list for the bug.

[Bug time/31558] mktime wildly mishandles times near Pacific/Apia tz discontinuity

[bugdal at aerifal dot cx]

https://sourceware.org/bugzilla/show_bug.cgi?id=31558

--- Comment #2 from Rich Felker <bugdal at aerifal dot cx> ---
The time_t value 1325329200 is part of the wrong *output*, not the input for
which it's bad. The correct localtime for t=1325329200 is "2012-01-01
01:00:00". So I don't see how "localtime produces the same wrong output" could
be correct.

What's wrong is that mktime is taking a broken-down input for "2011-12-31
00:00:00" with isdst=0 (mismatching that DST was active at that time) and,
rather than offsetting by +1 hour to get "2011-12-31 01:00:00" like it should,
is offsetting by 1 day + 1 hour. The wrong broken-down output and the time_t
output match each other.

-- 
You are receiving this mail because:
You are on the CC list for the bug.

[Bug time/31558] mktime wildly mishandles times near Pacific/Apia tz discontinuity

[schwab@linux-m68k.org]

https://sourceware.org/bugzilla/show_bug.cgi?id=31558

--- Comment #3 from Andreas Schwab <schwab@linux-m68k.org> ---
It's easy to mix up since 25 hours is exactly 90000 seconds.

-- 
You are receiving this mail because:
You are on the CC list for the bug.

[Bug time/31558] mktime wildly mishandles times near Pacific/Apia tz discontinuity

[schwab@linux-m68k.org]

https://sourceware.org/bugzilla/show_bug.cgi?id=31558

Andreas Schwab <schwab@linux-m68k.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |eggert at cs dot ucla.edu

-- 
You are receiving this mail because:
You are on the CC list for the bug.

[Bug time/31558] mktime wildly mishandles times near Pacific/Apia tz discontinuity

[eggert at cs dot ucla.edu]

https://sourceware.org/bugzilla/show_bug.cgi?id=31558

--- Comment #4 from eggert at cs dot ucla.edu ---
(In reply to Rich Felker from comment #0)
> Given tm_year=2011-1900, tm_mon=12-1, tm_mday=31, all other fields 0, and
> TZ=Pacific/Apia, glibc mktime produces an output of 2012-01-01 01:00:00
> (time_t 1325329200), offset a whole day forward from what it should be. The
> affected input is not even a time in the omitted day (2011-12-30 does not
> exist in this zone) but 1 hour into the following day, which exists. The
> problem seems to be related to how tm_isdst=0 is being applied - DST is
> active at this time - but with or without it applied, the time never falls
> into the limbo day.
> 
> Discovered as part of a monster thread about the topic of this zone
> transition on the musl libc mailing list.

I don't see a bug here. The input to mktime is ambiguous, since two periods of
standard time are plausible, either the one at -11 (e.g, from 2011-04-02 to
201-09-24) or the one at +13 (e.g., from 2012-04-02 to 2012-09-30). mktime is
free to choose either adjustment, and it chooses to adjust from the correct
time with tm_isdst=1 (which is +14) to the standard time offset of -11, and
this adjustment is 25 hours as reported. If mktime's input was derived by
adding 5 months to a 2011-07-31 timestamp this is the right thing to do; if it
was derived by subtracting 5 months from a 2012-05-31 timestamp this is the
wrong thing to do.

In time zones like Pacific/Apia with multiple standard time offsets (or
multiple DST offsets), this problem is inherent to mktime's poorly designed
API. mktime was designed assuming US rules circa 1980, and although it sort-of
works in a simple timezone with US-like rules in perpetuity, in other timezones
you cannot rely on mktime to do what you want with time arithmetic because it's
not always clear what you want.

-- 
You are receiving this mail because:
You are on the CC list for the bug.

[Bug time/31558] mktime wildly mishandles times near Pacific/Apia tz discontinuity

[schwab@linux-m68k.org]

https://sourceware.org/bugzilla/show_bug.cgi?id=31558

Andreas Schwab <schwab@linux-m68k.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|UNCONFIRMED                 |RESOLVED
         Resolution|---                         |NOTABUG

--- Comment #5 from Andreas Schwab <schwab@linux-m68k.org> ---
The right thing to do is to set tm_isdst to -1 if you don't know the actual
value.

-- 
You are receiving this mail because:
You are on the CC list for the bug.

[Bug time/31558] mktime wildly mishandles times near Pacific/Apia tz discontinuity

[bugdal at aerifal dot cx]

https://sourceware.org/bugzilla/show_bug.cgi?id=31558

Rich Felker <bugdal at aerifal dot cx> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
         Resolution|NOTABUG                     |---
             Status|RESOLVED                    |UNCONFIRMED

--- Comment #6 from Rich Felker <bugdal at aerifal dot cx> ---
> I don't see a bug here. The input to mktime is ambiguous, since two periods of standard time are plausible, either the one at -11 (e.g, from 2011-04-02 to 201-09-24) or the one at +13 (e.g., from 2012-04-02 to 2012-09-30).

This is NOT THE CASE. The input time is an unambiguous time *outside* of the
zone transition cut. The nonexistent (thus ambiguous) range is 2011-12-30
00:00:00 to 2011-12-30 23:59:59. The requested time is 2011-12-31 01:00:00, but
specified as "the time that would have been 00:00:00 if DST were not active".

Note that, even if it were handled as being in DST, this would *still* be
outside of the zone transition cut, so the bug shouldn't be a matter of
crossing the cut as an intermediate calculation. It's probably glibc using the
adjacent rule across the cut, rather than the adjacent opposite-DST-state rule
in spring, to adjust for tm_isdst not matching the DST state in effect at the
requested time.

> The right thing to do is to set tm_isdst to -1 if you don't know the actual value.

Setting tm_isdst=-1 is semantically completely different from setting
tm_isdst=0. tm_isdst=0 does not mean "we don't know if it's DST or not". It
means "we are asking mktime to normalize a time specified in terms of whether
it's given in DST or not, to the actual state of DST at that time". It would
arise in situations like requesting "now - 93 days" on April 2.

-- 
You are receiving this mail because:
You are on the CC list for the bug.

[Bug time/31558] mktime wildly mishandles times near Pacific/Apia tz discontinuity

[eggert at cs dot ucla.edu]

https://sourceware.org/bugzilla/show_bug.cgi?id=31558

--- Comment #7 from eggert at cs dot ucla.edu ---
(In reply to Rich Felker from comment #6)

> The input time is an unambiguous time *outside* of the
> zone transition cut.
It seems you misunderstood my comment. The requested input time does not exist,
because it is not a valid struct tm that would be returned by localtime. mktime
must therefore adjust the input time, by adjusting some of the struct tm
values. There are multiple plausible ways to do that adjustment, because this
zone has multiple DST offsets. That is why mktime's behavior is not fully
specified by the standard, and why the argument to mktime are ambiguous. It has
nothing to do with the time being in a fallback area.

> It's probably glibc using the adjacent rule across the cut, rather than the adjacent opposite-DST-state rule in spring
There is no information in the TZif file that will tell glibc which of the DST
offsets are "correct", for some definition of "correct". Perhaps glibc mktime
will luck out and agree with you, perhaps it won't. It's conforming to POSIX
either way.

-- 
You are receiving this mail because:
You are on the CC list for the bug.

[Bug time/31558] mktime wildly mishandles times near Pacific/Apia tz discontinuity

[bugdal at aerifal dot cx]

https://sourceware.org/bugzilla/show_bug.cgi?id=31558

--- Comment #8 from Rich Felker <bugdal at aerifal dot cx> ---
I'm not sure if you're aware, but the resolution of Austin Group tracker item
1627 has imposed further future requirements on mktime:

https://austingroupbugs.net/view.php?id=1627#c6415

I have not yet evaluated whether these together with other changes for Issue 8
will completely tie-down this case. It seems glibc is interpreting the
tm_isdst=0 as relative to the previous year's non-DST offset (two rules back)
rather than the next year's non-DST offset (an adjacent rule), and this may be
a permissible, albeit surprising, behavior.

-- 
You are receiving this mail because:
You are on the CC list for the bug.

[Bug time/31558] mktime wildly mishandles times near Pacific/Apia tz discontinuity

[eggert at cs dot ucla.edu]

https://sourceware.org/bugzilla/show_bug.cgi?id=31558

eggert at cs dot ucla.edu changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|UNCONFIRMED                 |RESOLVED
         Resolution|---                         |INVALID

--- Comment #9 from eggert at cs dot ucla.edu ---
(In reply to Rich Felker from comment #8)
> I'm not sure if you're aware, but the resolution of Austin Group tracker
> item 1627 has imposed further future requirements on mktime:

Yes, I'm aware of that Austin Group issue. When I mentioned POSIX above, I was
referring to IEEE P1003.1-202x/D4.1, February 2024, which is the latest draft I
know of, and which incorporates Austin DR 1627 with further updates. glibc
mktime conforms to this draft (as well as to the current POSIX), because for
this case the draft merely says "The time since the Epoch shall be corrected
for the offset of the local timezone’s standard time from Coordinated Universal
Time", and since Pacific/Apia has multiple standard time offsets, glibc is free
to choose whichever one it likes.

As I mentioned earlier, the TZif file does not record what the hypothetical
standard time offset would be during a period when DST is observed, so it
wouldn't really matter if POSIX said something like "the local timezone's
standard time that would have been effect at that moment if DST were not being
observed", as the information simply isn't in the TZif file (and often is not
even a well-defined question - the relevant legislation doesn't specify
either).

The converse can also happen: e.g., in America/St_Johns for 1989-01-01 00:00:00
with tm_isdst=1, it's plausible for mktime to adjust the time by either 1 hour
or 2 hours when setting tm_isdst=0, because St Johns observed double daylight
saving time as well as single, and the TZif file does not tell mktime which
offset to use when adjusting the struct tm in that case.

I'm going to boldly mark this report as not a bug; feel free to reopen it if
there continues to be a real question about it.

-- 
You are receiving this mail because:
You are on the CC list for the bug.