[Bug time/25387] New: year 2038 bug for localtime with leap seconds and DST

classic Classic list List threaded Threaded
2 messages Options
Reply | Threaded
Open this post in threaded view
|

[Bug time/25387] New: year 2038 bug for localtime with leap seconds and DST

glaubitz at physik dot fu-berlin.de
https://sourceware.org/bugzilla/show_bug.cgi?id=25387

            Bug ID: 25387
           Summary: year 2038 bug for localtime with leap seconds and DST
           Product: glibc
           Version: 2.30
            Status: NEW
          Severity: normal
          Priority: P2
         Component: time
          Assignee: unassigned at sourceware dot org
          Reporter: eggert at cs dot ucla.edu
  Target Milestone: ---

Created attachment 12209
  --> https://sourceware.org/bugzilla/attachment.cgi?id=12209&action=edit
exercise the Y2038 leap second bug

glibc localtime and related functions mishandle daylight saving time
transitions calculated from the TZ string of a TZif file, if the file has leap
seconds. One way to see the bug is to run the shell command:

zdump -i -c 2037,2039 right/America/Los_Angeles

on Fedora 31 x86-64. The output is:

        TZ="right/America/Los_Angeles"
        -       -       -08     PST
        2037-03-08      03      -07     PDT     1
        2037-11-01      01      -08     PST
        2038-03-14      02:59:33        -07     PDT     1
        2038-11-07      00:59:33        -08     PST

The transitions are correct through the year 2037, but starting in 2038 they
are off by 27 seconds (the number of leap seconds from 1972 until now).

To see the bug in glibc directly, compile and run the attached program
localtime-bug.c. The output is:

2152173599 - Sun Mar 14 01:59:32 2038
2152173600 - Sun Mar 14 02:59:33 2038

showing that localtime thinks the clock jumps forward at 01:59:33, whereas it
should jump forward at 02:00.

A similar bug appears in tzcode 2019c and earlier. I proposed a fix here:

https://mm.icann.org/pipermail/tz/2020-January/028792.html

and something like this fix should appear in the next tzdb release.

It might also be helpful for glibc to sync to the zic.c in tzdb 2020a (whenever
2020a comes out), as this should cause zic to omit the problematic transitions
from the installed TZif files. See:

https://mm.icann.org/pipermail/tz/2020-January/028794.html

--
You are receiving this mail because:
You are on the CC list for the bug.
Reply | Threaded
Open this post in threaded view
|

[Bug time/25387] year 2038 bug for localtime with leap seconds and DST

Sourceware - glibc-bugs mailing list
https://sourceware.org/bugzilla/show_bug.cgi?id=25387

--- Comment #1 from eggert at cs dot ucla.edu ---
(In reply to eggert from comment #0)

> It might also be helpful for glibc to sync to the zic.c in tzdb 2020a
> (whenever 2020a comes out), as this should cause zic to omit the problematic
> transitions from the installed TZif files.

I installed this change into glibc master, thus lowering the priority of the
bug as it now applies only to TZif files that were not generated by zic
(something that's unlikely).

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