Hallo Im using CentOS 7
Ist the 2038 year Problem solved in CentOS 7.5 64 bit Version
Thanks Johann Fock
Von meinem iPad gesendet
15 thoughts on - 2038 Year Problem
I got 2 years of work solving the year 2000 issue. In 2038 I will be
79 – maybe I will have to come out of retirement to work on that.
I doubt there is any one answer without a deep audit of all the binaries involved. Most date/clock code in 64 bit should be too big to care, but if you have any 32 bit code, then no idea.
CentOS 7 will probably be retired by then, so….I’m not going to worry about it…
If you define the problem as the limitations of system clock based on a
32-bit representation of seconds relative to the epoch, then the answer is “yes.” The Linux kernel uses a 64-bit clock on 64-bit systems.
Any given application may store dates in a format of its own choosing, though, so its possible that applications running on CentOS 7 could still have a problem.
It’s probably easier and faster to simply set the system clock of a test host to the year 2040 and test the system and its applications than it is to ask for opinions, though.
If you do that make sure it’s a system you’re happy to junk and reinstall. I have painful memories of trying to sort out systems we rolled forward over Y2K. Amongst other things the license manager became convinced we were trying to fiddle things. :-(
I don’t think I’ve ever said this but I am very envious of all these people who had loads of work due to Y2K or were paid obscene amounts of money to tend systems over new year’s eve/day.
I was working for an ISP at the time and got none of this. Nothing happened. I don’t even recall any special precautions being taken (apart from below). No over time, no obscene amounts of money.
Admittedly there was a Y2K audit earlier in the year and so I presume that the consultants who did it got paid some obscene amounts of money. As I recall, they found very little except for one major system that we knew would need updating anyway. And I presume that the contractor who came in to fix the major system was rather well paid too.
But no money for me. Wrong job, wrong time, wrong place, I guess. Perhaps I should be pleased the actual 99/00 changeover went so smoothly afterall.
Oops, sorry. This was off-topic here. I actually thought this was a different mail list where it would have been on-topic.
It only went smoothly because there were people like me fixing the issues ;-)
I worked on Wall St at the time, and I got a reputation for being able to find and fix Y2K issues. Really all that I did was grep the code bases for 2 digit years, and code that blindly added 1900 to them. There were a ton of those cases. It was not atypical for me to find
500-1000 or more such cases at each site. The fixes were easy but the testing took a while. I did this for banks, hedge funds, brokerages, bond traders, etc.
At one place where I had fixed probably 700 cases, after Y2K came and went without an incident the CEO said “You made such a big deal about this, and then nothing happened.”
Well, CentOS-7 will be EOL’ed on 30 June 2024 so does it matter?
Putting it another way .. the first ever CentOS release happened in 2004
(CentOS 3.1). That is 14 years ago. 2038 is 14 years AFTER CentOS-7 EOLs.
Who asks if anything runs on CentOS 3.1 right now?
At Wed, 3 Oct 2018 08:49:56 -0500 CentOS mailing list wrote:
It is my understanding that even 32-bit kernels since 2.6 (or maybe even 2.4)
use 64 bit system clocks. The “2038 year Problem” has been solved for some time…
there’s solved, then there’s solved.
anything that uses future dates later than 2038-ageddon will still have trouble, at least until such time as they are all recompiled against kernels and glibc that contain working mitigations. You can’t convince me that there aren’t a lot of programs and databases/files storing such things. and as time goes by it’ll get larger, even before 2038 hits.
If you have code which is calculating 20 year mortgages and a base CentOS program gives you negative time in 64 bits then it is a problem even if the OS is not going to be around in 2038. [This is where problems were showing up in 1998 and 2008 when 40 year and 30 year contracts/mortgages started getting used in some sort of software and getting weird times.]
Hey Johann,
You should submit this question to the Fedora mailing list. CentOS is downstream from Fedora. If the problem is not fixed there it will not be fixed in CentOS, no matter what the release number might be in 2038.
In that case perhaps I should take some of the credit for writing code that never had a Y2K problem in the first place. ;-)
I think this shows that it was partly an industry-related issue. At the ISP I mentioned, the vast majority of the systems were Y2K-compliant and had ended up that way through the normal process of upgrades and patches over many years. (Well, apart from the single, major semi-proprietary system we knew about anyway). However, your employer (and your employer’s industry) was very different: It clearly ran numerous disparate code bases, many developed in house, many of which were non-compliant and whose compliance was unknown until you found and fixed them.
15 thoughts on - 2038 Year Problem
I got 2 years of work solving the year 2000 issue. In 2038 I will be
79 – maybe I will have to come out of retirement to work on that.
I doubt there is any one answer without a deep audit of all the binaries involved. Most date/clock code in 64 bit should be too big to care, but if you have any 32 bit code, then no idea.
CentOS 7 will probably be retired by then, so….I’m not going to worry about it…
If you define the problem as the limitations of system clock based on a
32-bit representation of seconds relative to the epoch, then the answer is “yes.” The Linux kernel uses a 64-bit clock on 64-bit systems.
Any given application may store dates in a format of its own choosing, though, so its possible that applications running on CentOS 7 could still have a problem.
It’s probably easier and faster to simply set the system clock of a test host to the year 2040 and test the system and its applications than it is to ask for opinions, though.
If you do that make sure it’s a system you’re happy to junk and reinstall. I have painful memories of trying to sort out systems we rolled forward over Y2K. Amongst other things the license manager became convinced we were trying to fiddle things. :-(
I don’t think I’ve ever said this but I am very envious of all these people who had loads of work due to Y2K or were paid obscene amounts of money to tend systems over new year’s eve/day.
I was working for an ISP at the time and got none of this. Nothing happened. I don’t even recall any special precautions being taken (apart from below). No over time, no obscene amounts of money.
Admittedly there was a Y2K audit earlier in the year and so I presume that the consultants who did it got paid some obscene amounts of money. As I recall, they found very little except for one major system that we knew would need updating anyway. And I presume that the contractor who came in to fix the major system was rather well paid too.
But no money for me. Wrong job, wrong time, wrong place, I guess. Perhaps I should be pleased the actual 99/00 changeover went so smoothly afterall.
Oops, sorry. This was off-topic here. I actually thought this was a different mail list where it would have been on-topic.
It only went smoothly because there were people like me fixing the issues ;-)
I worked on Wall St at the time, and I got a reputation for being able to find and fix Y2K issues. Really all that I did was grep the code bases for 2 digit years, and code that blindly added 1900 to them. There were a ton of those cases. It was not atypical for me to find
500-1000 or more such cases at each site. The fixes were easy but the testing took a while. I did this for banks, hedge funds, brokerages, bond traders, etc.
At one place where I had fixed probably 700 cases, after Y2K came and went without an incident the CEO said “You made such a big deal about this, and then nothing happened.”
Well, CentOS-7 will be EOL’ed on 30 June 2024 so does it matter?
Putting it another way .. the first ever CentOS release happened in 2004
(CentOS 3.1). That is 14 years ago. 2038 is 14 years AFTER CentOS-7 EOLs.
Who asks if anything runs on CentOS 3.1 right now?
At Wed, 3 Oct 2018 08:49:56 -0500 CentOS mailing list wrote:
It is my understanding that even 32-bit kernels since 2.6 (or maybe even 2.4)
use 64 bit system clocks. The “2038 year Problem” has been solved for some time…
there’s solved, then there’s solved.
anything that uses future dates later than 2038-ageddon will still have trouble, at least until such time as they are all recompiled against kernels and glibc that contain working mitigations. You can’t convince me that there aren’t a lot of programs and databases/files storing such things. and as time goes by it’ll get larger, even before 2038 hits.
If you have code which is calculating 20 year mortgages and a base CentOS program gives you negative time in 64 bits then it is a problem even if the OS is not going to be around in 2038. [This is where problems were showing up in 1998 and 2008 when 40 year and 30 year contracts/mortgages started getting used in some sort of software and getting weird times.]
Hey Johann,
You should submit this question to the Fedora mailing list. CentOS is downstream from Fedora. If the problem is not fixed there it will not be fixed in CentOS, no matter what the release number might be in 2038.
—
_
°v°
/(_)\
^ ^ Mark LaPierre Registered Linux user No #267004
https://linuxcounter.net/
****
In that case perhaps I should take some of the credit for writing code that never had a Y2K problem in the first place. ;-)
I think this shows that it was partly an industry-related issue. At the ISP I mentioned, the vast majority of the systems were Y2K-compliant and had ended up that way through the normal process of upgrades and patches over many years. (Well, apart from the single, major semi-proprietary system we knew about anyway). However, your employer (and your employer’s industry) was very different: It clearly ran numerous disparate code bases, many developed in house, many of which were non-compliant and whose compliance was unknown until you found and fixed them.
I was definitely in the wrong industry!