Bug 63369 - mktime seems to have changed between glibc-2.2.5-30 and glibc-2.2.5-32
mktime seems to have changed between glibc-2.2.5-30 and glibc-2.2.5-32
Product: Red Hat Linux
Classification: Retired
Component: glibc (Show other bugs)
i386 Linux
medium Severity medium
: ---
: ---
Assigned To: Jakub Jelinek
Brian Brock
Depends On: 63361
Blocks: 61590
  Show dependency treegraph
Reported: 2002-04-12 20:20 EDT by Chip Turner
Modified: 2016-11-24 10:05 EST (History)
1 user (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2002-04-14 23:31:59 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)

  None (edit)
Description Chip Turner 2002-04-12 20:20:05 EDT
Description of Problem:
mktime has changed and is returning different values between the mentioned
versions of glibc.  Affects i386 and ia64 and perhaps more.  Demonstration
program and output when run on boris (glibc 2.2.5-30, but 2.2.5-32 inside buildroot)

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

        struct tm t;
        time_t result;
        t.tm_sec = 59;
        t.tm_min = 59;
        t.tm_hour = 23;
        t.tm_mday = 31;
        t.tm_mon = 11;
        t.tm_year = 69;

        result = mktime(&t);

        printf("time: %ld, %s", (long)result, ctime(&result));

        return 1;

[cturner@boris cturner]$ gcc -Wall test.c -o test
[cturner@boris cturner]$ ./test
time: 17999, Wed Dec 31 23:59:59 1969
[cturner@boris cturner]$ cp tes
[cturner@boris cturner]$ sudo /usr/sbin/chroot /mnt/build/beehive/dist-7.3-build/
[cturner@boris cturner]$ cp test.c /mnt/build/beehive/dist-7.3-build/tmp
[cturner@boris cturner]$ sudo su -
[root@boris root]# chroot /mnt/build/beehive/dist-7.3-build 
[root@boris /]# cd /tmp
[root@boris tmp]# gcc -Wall test.c -o test
[root@boris tmp]# ./test
time: -1, Wed Dec 31 18:59:59 1969
Comment 1 Chip Turner 2002-04-12 20:20:55 EDT
marked 63361 as depending on this
Comment 2 Jakub Jelinek 2002-04-12 20:57:19 EDT
Yes, this has changed.
See http://bugs.gnu.org/cgi-bin/gnatsweb.pl?debug=&database=default&cmd=view+audit-trail&cmd=view&pr=2738
            A value that approximates the number of seconds that have
            elapsed since the Epoch. A Coordinated Universal Time name
            (specified in terms of seconds (tm_sec), minutes (tm_min),
            hours (tm_hour), days since January 1 of the year (tm_yday),
            and calendar year minus 1900 (tm_year)) is related to a time
            represented as seconds since the Epoch, according to the
            expression below.

            If the year is <1970 or the value is negative, the
            relationship is undefined. If the year is 1970 and the value
            is non-negative, the value is related to a Coordinated
            Universal Time name according to the C-language expression,
            where tm_sec, tm_min, tm_hour, tm_yday, and tm_year are all

  And mktime is defined as:

    The mktime( ) function shall return the specified time since the
    Epoch encoded as a value of type time_t. If the time since the Epoch
    cannot be represented, the function shall return the value

  tm_year=69 means a year < 1970 and therefore undefined and cannot be

Was this some standard conformance suite or what have you used to find out
about this?
Comment 3 Bill Nottingham 2002-04-12 21:00:21 EDT
The time passed is interpreted as in the current timezone. Hence, the time since
the epoch *can* be represented.
Comment 4 Bill Nottingham 2002-04-12 21:06:20 EDT
As to what prompted this, this is what causes perl-Date-Calc to fail building,
as its test suite fails.
Comment 5 Jakub Jelinek 2002-04-13 17:24:35 EDT
was added into glibc-2.2.5-33. Can you please check it out?
Comment 6 Chip Turner 2002-04-13 22:47:07 EDT
Looks good, output of test.c on my workstation with glibc-2.2.5-33 is:
[cturner@minbar cturner]$ ./test
time: 17999, Wed Dec 31 23:59:59 1969

perl-Date-Calc also passes its tests now

Note You need to log in before you can comment on or make changes to this bug.