Announcement
Collapse
No announcement yet.
With Approaching Another Year Closer To Year 2038, Linux 5.5 Brings More Y2038 Fixes
Collapse
X
-
all devices in the wild have to support kernel updates, otherwise they will be running obsolete broken kernels very soon
-
Originally posted by CommunityMember View PostPerhaps because things happened before Jan 1st, 1970 (the zero epoch), and you wanted a way to be able to represent them?
a signed integer could have the advantage of detecting calculation errors, but I am not sure if there were much thoughts spent.
IMHO, the core OS should refrain from using absolute timestamps, just use some unsigned ring arithmeticCode:isexpired = (targettime - time) < (maxtime / 2)
Code:< (maxtime / 2)
- Likes 2
Leave a comment:
-
Originally posted by Britoid View Post
We'll be dead long before 403207347832.
- Likes 1
Leave a comment:
-
Originally posted by Raka555 View PostThe question is why would you want time_t that can go negative? You can make that mistake in any language.
- Likes 4
Leave a comment:
-
Originally posted by CommunityMember View PostI suppose one could boycott Unix (and its derivatives) and the C programming language (and their other contributions), on the principal the creators did not imagine that what they started as a research project would still be in use 60+ years later. That will show them!
- Likes 1
Leave a comment:
-
Originally posted by Raka555 View PostWho thought it was a good idea to store time as a signed integer
I suppose one could boycott Unix (and its derivatives) and the C programming language (and their other contributions), on the principal the creators did not imagine that what they started as a research project would still be in use 60+ years later. That will show them!
Leave a comment:
-
People seem to forget that even an 8-bit system can handle a uint64_t just fine. It's just a bit slower to handle.
You don't need to drop an entire architecture just because time_t was defined 32 bit and not 64 bit.
- Likes 1
Leave a comment:
-
Originally posted by DoMiNeLa10 View PostAre there any plans to deprecate i686 support? I'd love to see x86 getting dropped entirely.
And yes, I still expect to see 32-bit being in use in the future. Even RISC-V has a 32 bit implementation, and for the base low end processors that often consume milliwatts and cost under $1 to the manufacturer, there is little reason for anything else. Expect many of these devices to be installed, and run in production for years or decades without any updates. It is really hard to tell sometimes what larger system might end up relying on them, or how far past its expected end of service life they might run.
Mitigating the 2038 bug completely, as soon as possible, is a wise decision.
In case anyone is wondering about the Y2K bug? It was dead serious and real. It almost actually did cause the financial industry to crash. The only reason it didn't is a herculean effort by companies and developers to patch old systems. Anyone with any COBOL experience ate really well in the 90s, with stories of devs getting paid upwards of $300k/year, in 1990s dollars(about $500k in today's dollars) to fix the issue.
- Likes 1
Leave a comment:
-
Who thought it was a good idea to store time as a signed integer ...
We should be having a 2106 problem and not a 2038 one ...
Leave a comment:
Leave a comment: