Summary: | TimeStamp Overflow 2106 year | ||
---|---|---|---|
Product: | Base System | Reporter: | izhaqblues <everton.win32> |
Component: | bin | Assignee: | freebsd-bugs (Nobody) <bugs> |
Status: | Open --- | ||
Severity: | Affects Some People | ||
Priority: | --- | ||
Version: | 12.0-STABLE | ||
Hardware: | amd64 | ||
OS: | Any |
Description
izhaqblues
2019-02-26 19:51:53 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. 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. |