System call conversion for year 2038(lwn.net)
lwn.net
System call conversion for year 2038
http://lwn.net/SubscriberLink/643234/6e05b14dcd966636/
6 comments
NetBSD also switched over in 6.0 back in 2012.
And FreeBSD apparently started in 2001: http://mm.icann.org/pipermail/tz/2004-June/012487.html
While it did advance the state of the art in many things, Linux really clings to reinventing the wheel in obvious cases. NIH FTW.
While it did advance the state of the art in many things, Linux really clings to reinventing the wheel in obvious cases. NIH FTW.
There is a big difference: the *BSD systems have a tightly integrated base system, where kernel and libc are adapted to changes in lockstep, and there is no stable kernel ABI.
FreeBSD ABI stability is not guaranteed between major releases (only between minor releases), while OpenBSD does not even guarantee ABI stability between minor releases.
Linux and GNU libc are separate projects, and there are pretty strong compatibility guarantees for the Linux syscall ABI; the glibc ABI is also stable, and glibc uses ELF symbol versioning to provide older deprecated functions for compatibility.
This means the system is more modular, but at the cost that interface changes like changing 32-bit time_t to 64-bit require a lot more effort and coordination.
Of course the advantage of the Linux approach is that existing application binaries will continue to run, even ones that do syscalls directly or with statically linked libc.
----
Edited to add: actually it turns out you were wrong with your claim about 64-bit time_t in FreeBSD:
Here is the current trunk header where it defines a 32-bit time_t for the i386 architecture.
https://svnweb.freebsd.org/base/head/sys/x86/include/_types....
FreeBSD ABI stability is not guaranteed between major releases (only between minor releases), while OpenBSD does not even guarantee ABI stability between minor releases.
Linux and GNU libc are separate projects, and there are pretty strong compatibility guarantees for the Linux syscall ABI; the glibc ABI is also stable, and glibc uses ELF symbol versioning to provide older deprecated functions for compatibility.
This means the system is more modular, but at the cost that interface changes like changing 32-bit time_t to 64-bit require a lot more effort and coordination.
Of course the advantage of the Linux approach is that existing application binaries will continue to run, even ones that do syscalls directly or with statically linked libc.
----
Edited to add: actually it turns out you were wrong with your claim about 64-bit time_t in FreeBSD:
Here is the current trunk header where it defines a 32-bit time_t for the i386 architecture.
https://svnweb.freebsd.org/base/head/sys/x86/include/_types....
That was on 64 bit systems; those all switched a long time ago, despite the author of that thread disliking it...
While Linux certainly reinvents the wheel in some cases and NIHism exists everywhere, the syscall interface of an operating system is not the place where one can just lift BSD code and drop it in and expect it to work. This work needs to be done carefully in a Linux-specific way. The "NIH" approach is sort of a requirement.
Linux seems to have a policy of avoiding breaking changes. Nice for maintaining software, but it's not the best quality kernel as a result.
In all fairness, linux does this, on 32 bit platforms where time_t is 32 bit, to be binary backwards compatible, which is a different goal from what the BSDs do/did, which is a rip and replace approach, where you'll need to recompile applications.
So what this means, according to the comment by user Arnd at lws, is that even though I built a 64 bit time machine I still cannot travel further into the future than 2242 or further back than 1698? My life's work, ruined.
No, that's the option they didn't chose.
You won't be able to use ext4 though.
Edit: Unless you already...
You won't be able to use ext4 though.
Edit: Unless you already...
Don't they mention 2554 for unsigned 64-bit?
Also, wouldn't the kernel keep the original time? Time conversion could be performed in userland, with big integers.
Also, wouldn't the kernel keep the original time? Time conversion could be performed in userland, with big integers.
Time to use RISC-V processors. They can be 128-bit.
What if I want to go even farther? Can someone on HN tell me if 128 bits is enough to get me from the dawn of the universe to the end of time (at work so I can't do it myself for another 4 hours).
2^128 ~= 3.4 x 10^38 [0]
Age of the universe in seconds ~= 4.3 x 10^17 [1]
So assuming you're using an unsigned int to represent the number of seconds from the big bang, you'll still have ~ 10^21 seconds left on the clock (31.7 trillion years).
Unless you're working with a timeline that extends out to the heat death of the universe (10^100 -> 10^(10^56) years), 128 bits should be enough.
[0] https://www.wolframalpha.com/input/?i=2%5E128
[1] https://www.wolframalpha.com/input/?i=age+of+the+universe+in...
Age of the universe in seconds ~= 4.3 x 10^17 [1]
So assuming you're using an unsigned int to represent the number of seconds from the big bang, you'll still have ~ 10^21 seconds left on the clock (31.7 trillion years).
Unless you're working with a timeline that extends out to the heat death of the universe (10^100 -> 10^(10^56) years), 128 bits should be enough.
[0] https://www.wolframalpha.com/input/?i=2%5E128
[1] https://www.wolframalpha.com/input/?i=age+of+the+universe+in...
If you a single type that counts the number of Plank Time units (10^-44 s) from the big bang until the heat death of the universe, how many bits would you need?
If the heat death of the universe is 10^100 years, that's 6*10^150 plank times [1]. log_2(that) ~ 500 bits. So you'd probably go with 512 bits for a maximally-precise time type that will never need to be updated for either size or precision.
[1]: http://www.wolframalpha.com/input/?i=convert+10%5E100+years%...
If the heat death of the universe is 10^100 years, that's 6*10^150 plank times [1]. log_2(that) ~ 500 bits. So you'd probably go with 512 bits for a maximally-precise time type that will never need to be updated for either size or precision.
[1]: http://www.wolframalpha.com/input/?i=convert+10%5E100+years%...
Two points:
- Quantization of time is not a part any widely accepted physical theory, and the evidence we have so far is consistent with time being continuous. Timekeeping with Planck time units would be "nice" (well, "overkill" and "impossible" are two good words to come to mind as well), but there's no reason in theory that you can't go finer.
- When your time is this fine, you also need to talk in very specific ways about reference frames. Time passes at different rates at different altitudes, and relative velocities also screw with you. Where's your reference clock? In some inter-galactic space, stationary relative to the CMB?
- Quantization of time is not a part any widely accepted physical theory, and the evidence we have so far is consistent with time being continuous. Timekeeping with Planck time units would be "nice" (well, "overkill" and "impossible" are two good words to come to mind as well), but there's no reason in theory that you can't go finer.
- When your time is this fine, you also need to talk in very specific ways about reference frames. Time passes at different rates at different altitudes, and relative velocities also screw with you. Where's your reference clock? In some inter-galactic space, stationary relative to the CMB?
To be fair, this is more an exercise in taking "future-proofing" to a logical extreme than something practical (or even possible).
With that context I (arbitrarily) chose plank time to be the smallest possibly-ever usable (maybe not practical) time scale for timekeeping.
That's a good point about location. If we're going for extremes, we should put it in one of the especially large spaces between galaxy clusters: supervoids[0]! If there were a clock made at plank time frequency, I wonder how much of an effect structures would have on it at interstellar, intergalactic, and void space distances. At this accuracy (and these distances) I imagine the clock's own gravity would be a major source of time dilation.
Perhaps the best setup would be an extremely small (think the size of a virus) clock with a small support station that provides energy to it and reads ticks back, kept a few hundred thousand light-years away to avoid gravitational influence.
Another thing. 10^100 years is a long time. So long that if the time from the big bang to the heat death of the universe were one second long, the universe isn't even 1 plank time old yet. 10^100 years is so long it starts making sense to talk about the half-lives of elements that are considered perfectly stable. To make any clock that is designed to operate continuously for that long would be a crazy undertaking even for an interstellar civilization.
[0]: https://en.wikipedia.org/wiki/Void_(astronomy)
With that context I (arbitrarily) chose plank time to be the smallest possibly-ever usable (maybe not practical) time scale for timekeeping.
That's a good point about location. If we're going for extremes, we should put it in one of the especially large spaces between galaxy clusters: supervoids[0]! If there were a clock made at plank time frequency, I wonder how much of an effect structures would have on it at interstellar, intergalactic, and void space distances. At this accuracy (and these distances) I imagine the clock's own gravity would be a major source of time dilation.
Perhaps the best setup would be an extremely small (think the size of a virus) clock with a small support station that provides energy to it and reads ticks back, kept a few hundred thousand light-years away to avoid gravitational influence.
Another thing. 10^100 years is a long time. So long that if the time from the big bang to the heat death of the universe were one second long, the universe isn't even 1 plank time old yet. 10^100 years is so long it starts making sense to talk about the half-lives of elements that are considered perfectly stable. To make any clock that is designed to operate continuously for that long would be a crazy undertaking even for an interstellar civilization.
[0]: https://en.wikipedia.org/wiki/Void_(astronomy)
Well, a 128 bit integer can count up to 2¹²⁸-1 seconds; that's more than the number of seconds that have (according to current theories) passed since the birth of the universe:
http://wolframalpha.com/input/?i=age+of+universe+%3C+%282^12...
http://wolframalpha.com/input/?i=age+of+universe+%3C+%282^12...
Great news, I'll see you earlier, everyone!
You have: 2^128 seconds
You want: yottayears
* 10783128
If we decide to measure time in tenths of an attosecond, no, it won't do.
But if you want to measure in seconds, 64 bits are enough already.
But if you want to measure in seconds, 64 bits are enough already.
What this made me think of is how many 32 bit, Linux-based, microcontrollers and IoT devices are out there and in the making. Many of these might actually still be relied on 23 years from now.
It is worrying. A possible work around for the remaining 32-bit systems would be a patch to switch to using an unsigned 32-bit integer for time storage, however this will only work for systems that don't need to deal with dates before 1970, but pushes the problem back to 2106.
You also will have to be absolutely sure that those systems will never run code that compares timestamps using a signed 32-bit comparison. That means vetting all the code, not only the OS.
Even for devices where all the code is in ROM, that can be difficult. Source may be lacking, or there may be binary blobs bought from companies that do not exist anymore.
Even for devices where all the code is in ROM, that can be difficult. Source may be lacking, or there may be binary blobs bought from companies that do not exist anymore.
For embedded systems, PIC24 microcontrollers are still popular. Those are 16 bit microcontrollers typically used without operating system. The one I last wrote production software on will display incorrect dates in 2036, and there are no libraries available to mitigate that.
At least in my case the date weren't mission crucial, but I expect a lot of factory hardware to behave weirdly starting on either 7th February 2036 or 19. January 2038.
At least in my case the date weren't mission crucial, but I expect a lot of factory hardware to behave weirdly starting on either 7th February 2036 or 19. January 2038.
Why those two dates?
The 19th January 2038 is 2^31 seconds after the unix epoch, when 32 bit linux timestamps wrap around. On 16-bit PIC microcontrollers the default implementation of the gmtime function wraps already 0x0x7C55817F seconds after the unix epoch (I forgot why, it was probably about efficiency). That works out to 7th February 2036, likely catching a lot of companies off guard (seemingly everyone focuses on 2038). Some systems also use 1980 as the epoch, so maybe we'll see some problems again in 2048.
Calling it just the Year 2038 problem is misleading because lots of platforms and implementations add their own twist, skewing the crucial date by a few years. Linux is a big platform, but there are countless niche alternatives as processor resources get scarce or realtime requirements get tight.
Calling it just the Year 2038 problem is misleading because lots of platforms and implementations add their own twist, skewing the crucial date by a few years. Linux is a big platform, but there are countless niche alternatives as processor resources get scarce or realtime requirements get tight.
2036-02-07 06:28:16 UTC is 2^32 seconds after 1900-01-01 00:00:00 UTC. Some systems represent time using a 32-bit unsigned integer counting seconds since 1900.
1 JAN 1970 was a judicious choice for the UNIX epoch date; it allowed a 32-bit signed integer time_t type (counting seconds) to handle dates almost all the way back to the year 1900 as well as 'way into the future.
[deleted]
Very likely it's already to late for some systems. I wouldn't be surprised if some of the systems already in production will last until sometime after 2038.
Expecting short upgrade cycles is normal in software/computing, but for manufacturing 30 to 50 years doesn't seem unrealistic. 23 years is a very short time, even if we stay in the field of computing, mainframes are getting close to 23 year life cycles.
Expecting short upgrade cycles is normal in software/computing, but for manufacturing 30 to 50 years doesn't seem unrealistic. 23 years is a very short time, even if we stay in the field of computing, mainframes are getting close to 23 year life cycles.
Or, worse, actual binary protocols that use 32bit integers to represent time values.
Please don't post LWN subscriber-only content until it's released to the public. I value LWN and would like to see its subscriber numbers increase, not have its content poached by content aggregators.
I appreciate your concern, but we don't mind if an occasional subscriber link is posted this way. It gets us a lot of readers we might not otherwise reach and, with luck, leads to more subscribers going forward.
Fixing the kernel now gives applications >20 years to get fixed up. There will still be a huge scramble in the dying months of 2037...
[deleted]
http://www.openbsd.org/55.html