nav[aria-label="Primary Navigation"] { padding: 0; & ul { list-style: none; width: 100%; display: flex; flex-direction: row; justify-content: start; align-items: start; gap: 30px; padding: 0; & li { margin: 0; } & ul li { list-style: none; } } }

Y2K conversion leftover problem

skeleton567

I currently use QW2014 Premier and discovered this issue with Intuit's Y2K 'solution' that after 19 years has never been fixed. It concerns a bad design decision in the QIF file format that attempted to handle dates in different centuries.

Earlier discussion in this community lead to the discovery of the explanation that has lead to a work-around, not a solution, for my problem.

I have two Quicken assets that were acquired in the 1940's which I would like to add to and track in my financial history in Quicken. Then I want to export my data into a real relational database system since I now have nearly 100k transactions.

The issue concerns the file spec for the QIF format that contains a very unfortunate design decision. When I used a QIF to CSV file converter, which I'll get to shortly, I was getting data with historical data converted to future dates, such as 03/10/2043.

------------------------------------------------------------------------------------------
Here is what I found in the Quicken Community discussions:

https://community.quicken.com/discussion/7851012/im-using-quicken2016-on-windows-10-the-date-imports-as-1918-instead-of-2018-why

QIF's "solution" for the Y2K problem was to change dates of the form 3/18/19 to 3/18'19. The latter format, with the apostrophe, denotes years starting with 2000. The former format denotes years in the previous century.
------------------------------------------------------------------------------------------

While not exactly the same as my problem, it has lead to a solution for me.

Now a plug for the gentleman who solved my problem overnight. I use a very nice utility, one of several created by Sergiy Tytarenko of Propersoft, that is called QIF2CSV. The unfortunate decision by Intuit in the Y2K turmoil ricocheted off into an inherited problem for Sergiy in his utility.

In trying to handle the problem, Sergiy attempted a workaround based on the two-digit year instead of the presence of the 'invalid' character embedded in the date data. While apparently this has worked for most situations, it caused his utility to perpetuate an Intuit problem.

I communicated this finding to Sergiy, and he created what appears to be a working solution literally overnight and had a new version of his utility ready the next morning.

Now I realize that this is a very obscure situation that is not a large problem for most casual Quicken users, but if I'm thinking correctly, this KIND of solution to the Y2K problem has only delayed a real answer and will raise it's ugly head again.

The people responsible to Quicken need to get the QIF file spec fixed.

Software issues should never be corrected by modifying the data.

Find more posts tagged with

Comments

UKR

Is there a reason why you're not using 4-digit years?

It's my understanding that the settings of your system date may play a role in how a QIF file is created. If your system date settings display dates in 2-digit MM/DD/YY format, Mr. Y2K bug may bite you again. Setting it to display dates in 4-digit MM/DD/YYYY format may alleviate the problem.

There also is a setting in the system date dialog about a "100-year sliding window". You need to make sure that this setting considers the date ranges in your data file and correctly translates 1/1/40 to 1/1/1940 and not 1/1/2040

skeleton567

I use both 'short date' and 'long date' Windows settings as 4-digit years, have never done anything else. Everywhere else in Quicken other than the QIF export my dates seem to perform as 4-digit year, so yes, I use 4-digit years. The only place I've ever seen this in the QIF export.

In fact, my two oldest asset accounts, acquired in 1943 and 1961 both show the correct dates in the QW2014 register, such as 9/8/1943 and 6/1/1961, and the register detail displays correctly, date ranges seem to work correctly. It's just the QIF export that changes the first one to 9/8/2043.

My take is that they didn't want to bother with a real Y2K fix to the QIF specs and that is the reason for trying to use the apostrophe instead of the four-digit year.