Uncap Time?
- Thread starter Moptop
- Start date
DeltaMac
Tech
Interesting in theory (I suppose), but do you really believe that the time, as presented through a computer, will be restricted by code that would be more than 100 years old? I have no doubt that technology will not have any problem, as bits and bytes will not be very relevant in the days of the nano-tube computing technology, (or femto-tube, or whatever size -tube technology will be used in a 100 years). In fact, I will predict that computers will be using some form of grown bio-electronics - probably in the next quarter-century
I also think that Apple, Inc - in its present form - will no longer exist in 27,000 years, and any present-day computing technology will just be in some dusty history chamber as a curiosity.
Now, if you would be asking about a limitation some 5 or 10 years in the future, I would also expect that to be overcome, probably while you still care about it.
I also think that Apple, Inc - in its present form - will no longer exist in 27,000 years, and any present-day computing technology will just be in some dusty history chamber as a curiosity.
Now, if you would be asking about a limitation some 5 or 10 years in the future, I would also expect that to be overcome, probably while you still care about it.
Gnomo
Registered
Actually, Epoch ("Unix") Time fails for 32 bit systems on Jan 19, 2038 @ 03:14:07 UTC after which the time will rollover to 1901. This is known as the Y2K38 bug.
There is no way to remove the limit on your systems' clock because this it is a physical limitation built into the CPU.
The way a computer keeps track of time is to increment a counter. This counter has a limited number of digits. When you exceed the number of digits the number rolls over. Kinda like your car's odometer, except instead of rolling over to zero it rolls over to the largest possible negative number (don't ask, it's a binary thing).
The other half of the issue is that the algorithm used to convert that counter into a human readable date does not have the ability to tell if the counter had rolled over. Just like someone looking at your car's odometer wouldn't be able to tell (with any certainty) if your odometer had rolled over or not. So, the algorithm has to take the number at face value.
The solution to the problem is to add more possible places to the register so it can hold larger numbers. This is what the upgrade to 64bit processors will do. 64bits should give an effective date range of 300,000 years, plenty of time to prepare for the next upgrade to 128bit processors or whatever new technology comes along.
There is no way to remove the limit on your systems' clock because this it is a physical limitation built into the CPU.
The way a computer keeps track of time is to increment a counter. This counter has a limited number of digits. When you exceed the number of digits the number rolls over. Kinda like your car's odometer, except instead of rolling over to zero it rolls over to the largest possible negative number (don't ask, it's a binary thing).
The other half of the issue is that the algorithm used to convert that counter into a human readable date does not have the ability to tell if the counter had rolled over. Just like someone looking at your car's odometer wouldn't be able to tell (with any certainty) if your odometer had rolled over or not. So, the algorithm has to take the number at face value.
The solution to the problem is to add more possible places to the register so it can hold larger numbers. This is what the upgrade to 64bit processors will do. 64bits should give an effective date range of 300,000 years, plenty of time to prepare for the next upgrade to 128bit processors or whatever new technology comes along.
You can set a non-Gregorian time system in your system preferences. So if you switch to Buddhist or Jewish time for instance, you'll be beyond these limits. Or at least by using the Jewish time, you'll be already in year 6000-something... (even though the base still has the same limit as above, and the difference is applied as a mask).