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
On Tue, Oct 2, 2018 at 1:42 PM Johann Fock Johann.Fock@abas.de wrote:
Hallo Im using CentOS 7 Ist the 2038 year Problem solved in CentOS 7.5 64 bit Version
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.
On Tue, Oct 2, 2018 at 1:42 PM Johann Fock Johann.Fock@abas.de wrote:
Hallo Im using CentOS 7 Ist the 2038 year Problem solved in CentOS 7.5 64 bit Version
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. _______________________________________________ CentOS mailing list CentOS@centos.org https://lists.centos.org/mailman/listinfo/centos
Centos 7 will probably be retired by then, so....I'm not going to worry about it...
On 02/10/2018 18:46, Larry Martell wrote:
I got 2 years of work solving the year 2000 issue.
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. <sulk> Wrong job, wrong time, wrong place, I guess. Perhaps I should be pleased the actual 99/00 changeover went so smoothly afterall.
On Tue, Oct 2, 2018 at 9:46 PM Mark Rousell mark.rousell@signal100.com wrote:
On 02/10/2018 18:46, Larry Martell wrote:
I got 2 years of work solving the year 2000 issue.
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. <sulk> Wrong job, wrong time, wrong place, I guess. Perhaps I should be pleased the actual 99/00 changeover went so smoothly afterall.
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."
On 03/10/2018 14:31, Larry Martell wrote:
It only went smoothly because there were people like me fixing the issues ;-)
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 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."
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!
On Tue, 2 Oct 2018 at 13:42, Johann Fock Johann.Fock@abas.de wrote:
Hallo Im using CentOS 7 Ist the 2038 year Problem solved in CentOS 7.5 64 bit Version
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.
Thanks Johann Fock
Von meinem iPad gesendet _______________________________________________ CentOS mailing list CentOS@centos.org https://lists.centos.org/mailman/listinfo/centos
On 10/2/18 10:41 AM, Johann Fock wrote:
Ist the 2038 year Problem solved in CentOS 7.5 64 bit Version
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. :-(
On 02/10/18 20:07, Gordon Messmer wrote:
On 10/2/18 10:41 AM, Johann Fock wrote:
Ist the 2038 year Problem solved in CentOS 7.5 64 bit Version
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.
CentOS mailing list CentOS@centos.org https://lists.centos.org/mailman/listinfo/centos
On 10/03/2018 08:49 AM, Johnny Hughes wrote:
On 10/02/2018 12:41 PM, Johann Fock wrote:
Hallo Im using CentOS 7 Ist the 2038 year Problem solved in CentOS 7.5 64 bit Version
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 centos@centos.org wrote:
From: Johnny Hughes johnny@centos.org To: centos@centos.org Message-ID: fd4926e4-5430-7203-8f51-07d6ec4df2de@centos.org Subject: Re: [CentOS] 2038 year Problem References: 8831B7AE-76C1-4CF1-815C-EF52D4C5DE10@abas.de In-Reply-To: 8831B7AE-76C1-4CF1-815C-EF52D4C5DE10@abas.de
On 10/02/2018 12:41 PM, Johann Fock wrote:
Hallo Im using CentOS 7 Ist the 2038 year Problem solved in CentOS 7.5 64 bit Version
Well, CentOS-7 will be EOL'ed on 30 June 2024 so does it matter?
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...
Content-Description: OpenPGP digital signature
-----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (GNU/Linux)
iEYEARECAAYFAlu0yQQACgkQTKkMgmrBY7OL3QCdFv/zLj3XKrO/ZmSroy385U3w 6DgAnRdNhwgVbda9ePu5nqlnWmtCLeKx =Fq4j -----END PGP SIGNATURE-----
MIME-Version: 1.0
CentOS mailing list CentOS@centos.org https://lists.centos.org/mailman/listinfo/centos
On Wed, Oct 03, 2018 at 10:04:57AM -0400, Robert Heller wrote:
At Wed, 3 Oct 2018 08:49:56 -0500 CentOS mailing list centos@centos.org wrote:
From: Johnny Hughes johnny@centos.org To: centos@centos.org Message-ID: fd4926e4-5430-7203-8f51-07d6ec4df2de@centos.org Subject: Re: [CentOS] 2038 year Problem References: 8831B7AE-76C1-4CF1-815C-EF52D4C5DE10@abas.de In-Reply-To: 8831B7AE-76C1-4CF1-815C-EF52D4C5DE10@abas.de
On 10/02/2018 12:41 PM, Johann Fock wrote:
Hallo Im using CentOS 7 Ist the 2038 year Problem solved in CentOS 7.5 64 bit Version
Well, CentOS-7 will be EOL'ed on 30 June 2024 so does it matter?
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.
On Wed, 3 Oct 2018 at 09:50, Johnny Hughes johnny@centos.org wrote:
On 10/02/2018 12:41 PM, Johann Fock wrote:
Hallo Im using CentOS 7 Ist the 2038 year Problem solved in CentOS 7.5 64 bit Version
Well, CentOS-7 will be EOL'ed on 30 June 2024 so does it matter?
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.]
On 10/02/18 13:41, Johann Fock wrote:
Hallo Im using CentOS 7 Ist the 2038 year Problem solved in CentOS 7.5 64 bit Version
Thanks Johann Fock
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.
-
Fred Smith -
Gordon Messmer -
J Martin Rushton -
Jay Hart -
Johann Fock -
Johnny Hughes -
Larry Martell -
Mark LaPierre -
Mark Rousell -
Robert Heller -
Stephen John Smoogen