Date: Sat, 22 Oct 2022 03:08:11 +0000 From: bugzilla-noreply@freebsd.org To: bugs@FreeBSD.org Subject: [Bug 267266] maximum date off by 1900 years from 32-bit tm_year max value? Message-ID: <bug-267266-227@https.bugs.freebsd.org/bugzilla/>
next in thread | raw e-mail | index | archive | help
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D267266 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 yea= r 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 =3D time(NULL); t =3D gmtime(&now); printf("%s%ld %d\n", ctime(&now), now, t->tm_year); =3D> Sat Oct 22 03:06:43 2022 1666408003 122 It's unclear to me why FreeBSD then can't represent 67768036191676799. --=20 You are receiving this mail because: You are the assignee for the bug.=
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?bug-267266-227>