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.
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).
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:
You have: 2^128 seconds
You want: yottayears
* 10783128
The universe is less than 14 gigayears old. I don't know of any estimates of how long it will last, but by the Copernican principle we can expect it to be on the order of gigayears.
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.
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.
- 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.
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.
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.
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.
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.
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.
Today a commented on a bug report from someone who still hasn't migrated to a UTF-8 locale. And when POODLE happened, there were still servers on SSLv3. So, yeah. :-(
o time_t is now 64 bits on all platforms.
o From OpenBSD 5.5 onwards, OpenBSD is year 2038 ready
o The entire source tree (kernel, libraries, and userland
programs) has been carefully
and comprehensively audited to support 64-bit time_t.
o Userland programs that were changed include arp(8),
bgpd(8), calendar(8), cron(8), find(1),
fsck_ffs(8), ifconfig(8), ksh(1), ld(1), ld.so(1),
netstat(1), pfctl(8), ping(8), rtadvd(8), ssh(1),
tar(1), tmux(1), top(1), and many others, including
games!
o Removed time_t from network, on-disk, and database
formats.
o Removed as many (time_t) casts as possible.
o Format strings were converted to use %lld and (long
long) casts.
o Uses of timeval were converted to timespec where
possible.
o Parts of the system that could not use 64-bit
time_t were converted to use unsigned 32-bit instead,
so they are good till the year 2106.
o Numerous ports throughout the ports tree received
time_t fixes.
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.
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.
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.
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.
38 comments
[ 3.2 ms ] story [ 88.8 ms ] threadhttp://wolframalpha.com/input/?i=age+of+universe+%3C+%282^12...
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...
But if you want to measure in seconds, 64 bits are enough already.
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%...
- 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?
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)
Also, wouldn't the kernel keep the original time? Time conversion could be performed in userland, with big integers.
You won't be able to use ext4 though.
Edit: Unless you already...
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.
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.
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.
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.
http://www.openbsd.org/55.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.
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....