[Bug time/34480] New: mktime fails to determine DST for America/Vancouver from tzdata 2026b

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

            Bug ID: 34480
           Summary: mktime fails to determine DST for America/Vancouver
                    from tzdata 2026b
           Product: glibc
           Version: unspecified
            Status: NEW
          Severity: normal
          Priority: P2
         Component: time
          Assignee: unassigned at sourceware dot org
          Reporter: aurelien at aurel32 dot net
  Target Milestone: ---

Created attachment 16904
  --> https://sourceware.org/bugzilla/attachment.cgi?id=3D16904&action=3Ded=
it
Simple reproducer

When mktime is called for the America/Vancouver from tzdata 2026b with tm_i=
sdst
=3D 0, it forces tm_isdst to 1 for dates <=3D 2026-06-05, but keeps it to 0=
 for
dates >=3D 2026-06-06. This didn't happen with tzdata 2026a, which however
consider an endless non-DST/DST alternation.

This can be seen with the attached reproducer. When executed with
TZ=3DAmerica/Vancouver on tzdata 2026a, it outputs:

mktime(2026-06-05 00:00:00)
mktime(2026-06-05 01:00:00) =3D 1783238400
mktime(2026-06-06 00:00:00)
mktime(2026-06-06 01:00:00) =3D 1783324800
difference: 86400

With tzdata 2026b it outputs:

mktime(2026-06-05 00:00:00)
mktime(2026-06-05 01:00:00) =3D 1783238400
mktime(2026-06-06 00:00:00)
mktime(2026-06-06 00:00:00) =3D 1783321200
difference: 82800

However both tzdata versions produce the same result when tm_isdst =3D -1.

All that said, POSIX 2024 clarifies the mktime behaviour: when tm_isdst is =
0,
the implementation should interpret the input as standard time and not atte=
mpt
to determine if DST is active. Maybe that is the correct fix here.

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