Bug 236065 - TimeStamp Overflow 2106 year
Summary: TimeStamp Overflow 2106 year
Status: Open
Alias: None
Product: Base System
Classification: Unclassified
Component: bin (show other bugs)
Version: 12.0-STABLE
Hardware: amd64 Any
: --- Affects Some People
Assignee: freebsd-bugs (Nobody)
Depends on:
Reported: 2019-02-26 19:51 UTC by izhaqblues
Modified: 2021-05-21 00:23 UTC (History)
0 users

See Also:


Note You need to log in before you can comment on or make changes to this bug.
Description izhaqblues 2019-02-26 19:51:53 UTC
Hi, are you ok?
I work doing tests, and I found one possible in a decentralized system that is used worldwide.
I want to simulate a specific date in the 22nd century;
however when I define the system with the date: 01/01/2106 00:00; 

the system reports an error. 

if I enter another date, for exemple: 01/01/2105 00:00 
the freebsd allows it to be changed. 

but after the reboot. it sets to: 01/01/2005 00:00;

I found some information on:


there is a possibility that I compile the system to use the size uint64? 

according to the wikipedia topic:

FreeBSD uses 64-bit time_t for all 32-bit and 64-bit architectures except 32-bit i386[11].

if the field actually has 64 bits, it can even be used after 2107 (which is the date I need);
Comment 1 Conrad Meyer freebsd_committer 2019-02-26 20:13:36 UTC
How are you setting the date and reading the date?

FreeBSD does use 64-bit for time_t on amd64, but cannot control the hardware clock's range.  Given you observe the correct date prior to reboot, I think we're probably doing the right thing in the OS.

I believe the lost range after reboot is due to a limitation of your PC hardware's clock (atrtc(4)), which uses two digits of binary-coded decimal for the year; years wrap at exactly 100 years, which is what you observed.
Comment 2 izhaqblues 2019-02-28 03:18:02 UTC
Conrand thank you for your return.

you response only one question, about 'reboot' after change 2105.

but and my other question?

about the year 2107;

I wanna test only, I do not care about backwards compatibility.
I tested it on a virtualBOx, but is there any way to do this test using some other kind of virtualization? 

Xen can solve my problem of 2105 but my doubt is how to make the kernel see the date of 2107. even though I can not do a reboot.
Comment 3 Mark Linimon freebsd_committer freebsd_triage 2021-05-21 00:23:11 UTC
^Triage: this does not seem to be "in progress" at this point.