[Bug libc/16301] Inconsistency/bug in mktime?

[Bug libc/16301] Inconsistency/bug in mktime?

[marcin.zukowski at gmail dot com]

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

Marcin <marcin.zukowski at gmail dot com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |marcin.zukowski at gmail dot com

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

[Bug libc/16301] New: Inconsistency/bug in mktime?

[marcin.zukowski at gmail dot com]

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

            Bug ID: 16301
           Summary: Inconsistency/bug in mktime?
           Product: glibc
           Version: 2.12
            Status: NEW
          Severity: minor
          Priority: P2
         Component: libc
          Assignee: unassigned at sourceware dot org
          Reporter: marcin.zukowski at gmail dot com
                CC: drepper.fsp at gmail dot com

[Disclaimer: first raised it on StackOverflow here:
http://stackoverflow.com/questions/20413853/bug-in-mktime-on-centos]

I have been playing with mktime, and I noticed a weird, and inconsistent,
behavior.

I provide it with a date which is not during DST (daylight saving time), but
with tm_isdst is set to 1, what mktime usually does is change tm_isdst to 0,
and adjust the time accordingly, shifting by 1 hour.

However, in the time period roughly in years 1928..1933 (couldn't find a
different range), the behavior is different. The tm_isdst field is set to 0,
but the time does not change. This results in weirdness when performing time
computations etc.

I have a tiny test program which for a given input date prints: original struct
tm, struct tm after calling mktime on it, mktime result, and struct tm which is
the result of calling localtime on the mktime result (should represent the same
moment in time as the original one).

The output is:

    2013-01-01 12:00:00 (off=0, dst=1) -> 2013-01-01 11:00:00 (off=-28800,
dst=0) ->   1357066800 -> 2013-01-01 11:00:00 (off=-28800, dst=0)
    1927-01-01 12:00:00 (off=0, dst=1) -> 1927-01-01 11:00:00 (off=-28800,
dst=0) ->  -1356930000 -> 1927-01-01 11:00:00 (off=-28800, dst=0)
    1929-01-01 12:00:00 (off=0, dst=1) -> 1929-01-01 12:00:00 (off=-28800,
dst=0) ->  -1293768000 -> 1929-01-01 12:00:00 (off=-28800, dst=0)
    1932-01-01 12:00:00 (off=0, dst=1) -> 1932-01-01 12:00:00 (off=-28800,
dst=0) ->  -1199160000 -> 1932-01-01 12:00:00 (off=-28800, dst=0)
    1934-01-01 12:00:00 (off=0, dst=1) -> 1934-01-01 11:00:00 (off=-28800,
dst=0) ->  -1136005200 -> 1934-01-01 11:00:00 (off=-28800, dst=0)

See that for years 2013, 1927, 1934, the hour is changed and dst set to 0. But
in years 1929 and 1932 the hour is not changed, but dst is.

Seems this is related to this code in glibc:
https://sourceware.org/git/?p=glibc.git;a=blob;f=time/mktime.c;hb=f1d70dad5381352b3cad04b5ee0dd0efe2627683#l501

The 'delta_bound' limits how far we search, and for this period 1928-1933, we
can't get to any period with isdst = 1.


Test test program is below and also available [here][1]

    #include <time.h>
    #include <stdio.h>
    #include <string.h>
    #include <stdlib.h>

    char* printtm(struct tm tm)
    {
      static char buf[100];
      sprintf(buf, "%04d-%02d-%02d %02d:%02d:%02d (off=%ld, dst=%d)",
        tm.tm_year + 1900, tm.tm_mon + 1, tm.tm_mday,
        tm.tm_hour, tm.tm_min, tm.tm_sec,
        tm.tm_gmtoff, tm.tm_isdst);
      return buf;
    }

    void test(int y, int m, int d, int hh, int mm, int ss, int isdst)
    {
      // Prepare tm structs
      struct tm tm, tm2;
      memset(&tm, 0, sizeof(tm));
      memset(&tm2, 0, sizeof(tm));
      tm.tm_year = y - 1900;
      tm.tm_mon = m - 1;
      tm.tm_mday = d;
      tm.tm_hour = hh;
      tm.tm_min = mm;
      tm.tm_sec = ss;
      tm.tm_isdst = isdst;
      // Convert tm -> t -> tm and print
      printf("%s -> ", printtm(tm));
      time_t t = mktime(&tm);
      printf("%s -> ", printtm(tm));
      printf("%12ld -> ", t);
      localtime_r(&t, &tm2);
      printf("%s\n", printtm(tm));
    }

    int main()
    {
      setenv("TZ", ":America/Los_Angeles", 1);
      tzset();

      test(2013,07,01, 12,0,0, 1);
      test(2013,01,01, 12,0,0, 1);
      test(1927,01,01, 12,0,0, 1);
      test(1929,01,01, 12,0,0, 1);
      test(1932,01,01, 12,0,0, 1);
      test(1934,01,01, 12,0,0, 1);
      return 0;
    }

  [1]: http://pastebin.com/EfPJuHiQ

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

[Bug libc/16301] Inconsistency/bug in mktime?

[fweimer at redhat dot com]

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

Florian Weimer <fweimer at redhat dot com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
              Flags|                            |security-

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

[Bug time/16301] Inconsistency/bug in mktime?

[jsm28 at gcc dot gnu.org]

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

Joseph Myers <jsm28 at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
          Component|libc                        |time

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