Y2K Bug… again?
Unless you are under 20, anyone?, anyone?… most of you will remember the Y2K panic of 1999.
The late 1990s were defined by a number of ridiculous things, but somewhere near the top of the list was the panic that boiled over in 1999 as people prepared for the end of civilization as we knew it.
Because of the “Y2K” bug, you see, anything and everything controlled by a computer would stop functioning when the clock struck midnight and December 31, 1999 rolled into January 1, 2000.
That obviously didn’t happen, but the Y2K bug was a pretty sizable nightmare for programmers as they were made to pour through code and change two-digit year abbreviations to four digits.
What was (or is) the Y2K bug?
When complicated computer programs were being written during the 1960s through the 1980s, computer engineers used a two-digit code for the year.
The “19” was left out. Instead of a date reading 1970, it read 70. Engineers shortened the date because data storage in computers was costly and took up a lot of space.
As the year 2000 approached, computer programmers realized that computers might not interpret 00 as 2000, but as 1900.
Activities that were programmed on a daily or yearly basis would be damaged or flawed.
As December 31, 1999, turned into January 1, 2000, computers might interpret December 31, 1999, turning into January 1, 1900.
The fix was to expand the year portion of the date to 4 digits. A pretty simple fix, although I spent many hours switching all the date fields in flowerSoft from mm/dd/yy to mm/dd/yyyy.
But wait… can this Y2K bug, who we thought was totally out of our lives be causing problems again?
Maybe. Perhaps you have even experienced it in flowerSoft.
Unfortunately, it looks like some programmers’ jobs still aren’t done.
The Associated Press reports that Y2K is back with a bang in Pennsylvania, where the families of 14,000 deceased men were just sent notices that their dearly departed must register for the draft or face fines and even imprisonment.
The men were all born between 1893 and 1897, so the youngest among them would be 116 or 117 years old right now.
So how is the bug coming back to haunt you? Well, because of the fix that was used to correct the problem in flowerSoft and other databases.
Because many users were still using databases like flowerSoft with a mm/dd/yy date format, there had to be a way to distinguish the century when a date such as 02/14/00 was used.
Was it 02/14/1900 or 02/14/2000?
That gave birth to a setting still being used in flowerSoft called PFCMARK. This setting is followed by a number which tells the database (flowerSoft) which century the 2-digit year is for.
Back in 2000, I set the PFCMARK=20 in flowerSoft’s environment because at that time it seemed like the most logical number.
That meant that any 2-digit year from 00 to 19 was assumed to be in the 21st century and any 2-digit year from 20 to 99 was assumed to be in the 20th century.
So if you had an employee that was born in 05/02/86, flowerSoft would know that you meant 05/02/1986.
If you had an order date of 05/02/12, flowerSoft knew it was really 05/02/2012.
In short, with PFCMARK=20, flowerSoft translated any 2-digit year from 00 through 19 to 2000 through 2019.
Any 2-digit year from 20 through 99 was translated to 1920 through 1999.
So what is happening now?
After all, flowerSoft uses 4-digit years throughout all its modules. Why is there a potential problem?
The problem is that credit card expiration dates are still being inputed as 2-digit years.
Credit cards are beginning to come in with expiration dates in 2020. When the expiration dates is inputted into flowerSoft, it is done as 09/20 for example.
With PFCMARK set as 20, flowerSoft thinks that date is really in 1920 and is flagging any new credit cards from customers expiring in 2020 as expired.
I’ve been changing the PFCMARK setting to 25 to avoid this problem, at least for another 5 years but then I would have to do it again.
So what I’ve come up with a better solution and that is to set the PFCMARK variable each time you log into flowerSoft by adding 10 the current year.
So, if you log into flowerSoft anytime during 2015, the PFCMARK would be set to 25. In 2016, the PFCMARK would be equal to 26 and so on.
Since the PFCMARK would change every year, you should never have a problem with dates anymore…
Unless, of course when we get to the year 2038. That problem will not affect flowerSoft buy may impact flowerSoft users.
But that is a different story.
If you want to read about it, here is the link… http://www.theguardian.com/technology/2014/dec/17/is-the-year-2038-problem-the-new-y2k-bug
The year 2038 problem is caused by 32-bit processors and the limitations of the 32-bit systems they power. The processor is the central component that drives all computers and computing devices. It crunches the numbers and performs calculations that allow programs to run.
Essentially, when the year 2038 strikes 03:14:07 UTC on 19 March, computers still using 32-bit systems to store and process the date and time won’t be able to cope with the date and time change. Like the Y2K bug, the computers won’t be able to tell the difference between the year 2038 and 1970 – the year after which all current computer systems measure time.