3 ms·
Closing in on the Y2K38 problem.
by jl6 4y ago
Closing in on the Y2K38 problem.
- onion2k 4y agoNooooo! The Y2K38 problem is already here. It is not a problem that will happen in 2038. It is a problem with storing and processing dates past 2038. For example, if you work in a bank and you have a system to store mortgage information that includes the epoch timestamp that someone's 25 year mortgage will end that means you need to store a date that is in 2047. If you do that using an epoch timestamp on a system that's using a 32 bit timestamp it'll overflow and return a date before the epoch instead. Do not imagine that Y2K38 is something to put off until nearer the time. You need to be thinking about it right now.
- lupire 4y agoWhat's wrong with dates before the epoch? Subtraction of rolled over unsigned ints works.
- lucb1e 4y agoSo long as you know it was before 1970, and after 1970-(2038-1970)=1902, you can recover the original date, yes.
- coderintherye 4y agoI'm kind of both horrified and impressed that this very solution is likely in place in some codebases.
- onion2k 4y agoThe fix itself doesn't need to be complicated for it to be hard to actually implement. A lot of apps that are affected probably haven't been deployed in years. Some won't have any source code available. Others won't have any docs, or tests, or even developers who know the right language. Fixing simple issues in old apps is hard.
- N19PEDL2 4y agoAre 32-bit systems still around? I mean other than some old embedded system that will likely be decommissioned well before 2038.
- GuB-42 4y agoEven in 64 bit systems, some numbers are stored as 32 bit integers. And 32 bit systems can process 64 bit numbers, they are just slower at it. It is a software and standardization problem, not hardware.