Replace Y2K with PTSD
Post Trump Systems Disaster
Groan.
The US Office of Management and Budget (OMB) has announced rule changes that – among other things – will finally end the requirement that agency IT departments report their Y2K compliance, only almost two decades after the event. A memo [PDF] published by the White House lays out a set of rollbacks to the reporting …
This post has been deleted by its author
This reminded me of a job I saw in 1999. Was a 6 month contract worth $120,000 for a Y2K IT specialist to oversee corporate preparations for the New Year.
Contract end date was December 31st, 1999
I didn't apply as I'd just started a new job, but man was I tempted to get that easy money.
I'm guessing you're not old enough to understand what the crux of the problem was.
History lesson. Back in the old days when memory space was very expensive developers saved memory by coding the year in two digits, This worked well in the 60's and 70's, but by the time the 90's came along many people realised all sorts of odd things could happen when the date ticked over from 99 to 00.
2099 to 2100 shouldn't be an issue
>I'm guessing you're not old enough to understand what the crux of the problem was.
Actually, I am, even fixed a couple of minor Y2K bugs back then. And after Y2K, I have seen applications again start assuming 2-digit years, just for convenience, only difference being they are now 20xx dates. Memory usage isn't really the problem, but the laziness of developers and users...
Besides, many Y2K fixes were really hacks that assumed 20xx after some cut-off year. They run into trouble even before 2100!
"Besides, many Y2K fixes were really hacks that assumed 20xx after some cut-off year. They run into trouble even before 2100!"
Yes, I vaguely remember that there were fixes on some systems that were more like somewhat questionable workarounds that pushed the problem from 1999 to 2019; the thinking being "that will give us enough time to either fix the problem or replace the systems completely". Well, time's nearly up - does anybody know whether this is still an issue?
2099 to 2100 shouldn't be an issue
Pfff... Many Y2K fixes just changed the window in which two digits were mapped onto four.
And the current crop of young whippersnappers seem only to keen to make the same mistakes all over again.
And I bet FAT32 will still be around because nobody seems willing to be the first to move to something sensible like UDF. And FAT32's maximum year? Yes, 2099.
"Pfff... Many Y2K fixes just changed the window in which two digits were mapped onto four."
It's still there in spreadsheet programs if you enter years as 2 digits.
The default in the current version of LibreOffice is to treat 2 digit year inputs as values between 1930 and 2029. See Options/Preferences -> General for that setting.
(I don't have a copy of Excel handy at the moment, so sorry, I can't check that)
There are still a lot of systems which use 2 digit years in output logs or CSV equivalents. Guess what happens when you import them into spreadsheets?
"This worked well in the 60's and 70's, but by the time the 90's came along many people realised all sorts of odd things could happen when the date ticked over from 99 to 00."
FYI, many people were aware of the issue as early as the 70's and earlier. Pensions, mortgages etc doing valuations many years into the future, long term payment schedules etc. It wasn't generally considered, but there people and industries affected and thinking about long before the BBC told Joe Public there would an ITpocalypse!
Whilst many people did get it some were not so smart. I had a developer working for me who wrote code in September 1999 with a Y2K bug in it! Never underestimate people's capacity for incompetence. Fortunately he wasn't working for me by the end of that year.
I also had a manager who was very smart but hadn't quite grasped the subtleties of what day followed February 28th 2000. As we discussed potential Y2K issues and briefly argued about the leap year he realized that code he had written a few years earlier was going to break. Not incompetence in his case, just a simple miscomprehension of the facts.
Some solutions will be OK until the date length needs to expand to 5 digits, and barring really major improvements in healthcare I doubt any of us will be around (in any form) for that event.
Of course those who used some quick & dirty flag to fix it may have a bit more of a problem.
33 bits however... Y2K38 is coming
Actually it's 32 bits that's the problem. Roll over into the top bit of a signed time value. Even if the OS is 64 bit there will be file systems or data formats that use 32 bit time values. For some cases treating the value as unsigned kicks the problem 68 years down the road, but for anything using historical data before 1970 that's not possible.
I have a possible defense.
PHB "I see from our records Mr Smith that you did the last year mods on this program and we've confirmed you were the John Smith on the change log."
Me:" I could only afford the low res brain scan for my personality recording and they may have missed a few things. What's a COBOL developer?"
PHB "The computer language, COBOL."
Me."No, I mean what's a developer?"
"COBOL has been a fossil since 1980 at least and that's over a working lifetime ago."
And yet here I am, not yet at retirement age, nor even yet officially considered a senior citizen. At least not by U.S. standards. I started working in 1975, I'm only 60, so you're off by at least a decade.
Not that I am interested in retiring at 65, but just using that as a standard.
Probably at least one a year from each reporting body. Basic rule of civil service procedures the world over: once you start something it just continues until you take positive action to stop it. It obvious thing would have been about June 2000 to do a post-implementation review and stop the reporting apart from any remaining issues.
Is also that the year 2100 is NOT a leap year. That is going to make lots of things break. Microsoft had to do lots of things to make/unmake/make the year 1900 a leap year.
The simple solution to the Y2038 problem is to use unsigned as time_t. Then it is officially not my problem
Of course, governments are governments and they will ALWAYS screw up things.
"The simple solution to the Y2038 problem is to use unsigned as time_t. "
should be 64-biits, actually.
Looks like 32-bit linux still has 32-bit integer as time_t [the libc would have to be updated, most likely]
64-bit linux has it as a 64-bit integer, however. no problems there.
but I'm pretty sure that the 'time since epoch' i being stored internally as 64-bits within the kernel. If someone finds differently, it would be interesting to know.
however it looks like libc itself (on 32-bit machines) needs to be fixed.
Actually, this is a bad time to cancel Y2K compliance, as some more bugs are going to start crawling out of the woodwork in 2018, as the children born in 2000 turn 18 years old and start signing up for services as adults. Banks and financial services in particular could be affected.
We hit a Y2K bug at work in 2014 as some government-assigned IDs issued in the jurisdiction where I live are given from the age of 14, and they use a 2-digit year (we validate age from the ID).
This is also happening for some systems that i have to use as a teacher. What is particularly galling is that in my previous life as a developer, i designed those systems and they were y2k compliant when written in 1987! Admittedly the code has changed, but 95%of my database design is still inuse, with extra tables for new functionality
Food and medicine here in Canada often come with a "best before date", known elsewhere as an Expiration Date or Expiry Date. In the early times, months were often coded in two letters but of course MA could be March or May. JU could be June or July. So to make the code more readable by humans, they used the first and third letters: MR, MY, JN, JL. Problem solved? No, in recent months I've started to see MA again. Nimrods. No offence intended towards people named Nimrod.
I worked for an organization that offered life memberships. How to code that? In the 1970s, when this problem was initially encountered, it was with the expiry date 1999-12-31. The date arithmetic would always work out (whether in 2-digit or 4-digit year formats), at least for a couple of decades. Of course, if somebody's membership expired on 1989-12-31, and they bought a 10-year extension, you'd fudge it by giving that person an extra day. It was a nominal expiry date. It should never be published verbatim, but sometimes in those days computer processing could be too primitive. The nominal date would slip out, and complaints would trickle in.
Around 1980, I computerized the membership database. I used two-digit years. I knew that the code would need to be massaged in less than two decades. Had nobody heard of code maintenance? Using two-digit year codes was often drawn in the popular press as lack of foresight, but I am unrepentant still.