[Bug 267266] maximum date off by 1900 years from 32-bit tm_year max value?

From: <bugzilla-noreply_at_freebsd.org>
Date: Sat, 22 Oct 2022 03:08:11 UTC
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=267266

            Bug ID: 267266
           Summary: maximum date off by 1900 years from 32-bit tm_year max
                    value?
           Product: Base System
           Version: 13.1-RELEASE
          Hardware: Any
                OS: Any
            Status: New
          Severity: Affects Only Me
          Priority: ---
         Component: kern
          Assignee: bugs@FreeBSD.org
          Reporter: jschauma@netmeister.org

With tm_year being a signed 32-bit int, the maximum date I should be able to
represent ought to be

Wed Dec 31 23:59:59 UTC 2147485547

which is epoch 67768036191676799.

This works on Linux and NetBSD, for example, as well as macOS.

On FreeBSD 13.1R, however, it does not:

$ date -r 67768036191676799
date: invalid time
$ date -r 67767976233532799
Tue Dec 31 23:59:59 UTC 2147483647
$ date -r 67767976233532800
date: invalid time

Note that here the maximum value (epoch 67767976233532799) is in the year
2147483647, not in the year 2147485547.  The difference between the two is
1900, suggesting that FreeBSD somehow counts tm_year as starting at the year 0,
not 1900.  However, I can't identify where/when that is the case, as other
dates correctly display tm_year as "year - 1900":


        struct tm *t;
        time_t now = time(NULL);

        t = gmtime(&now);
        printf("%s%ld %d\n", ctime(&now), now, t->tm_year);

=>

Sat Oct 22 03:06:43 2022
1666408003 122

It's unclear to me why FreeBSD then can't represent 67768036191676799.

-- 
You are receiving this mail because:
You are the assignee for the bug.