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: https://en.wikipedia.org/wiki/Year_2038_problem 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);
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.
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.
^Triage: this does not seem to be "in progress" at this point.