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; } } }

Entry Date stops at 31 December 2027 in QW5

Higgy1higgy

I have been running Quicken 5 for a long time now on win XP Dell PC and think I have implemented the Y2K fix also a long time ago . (26 yrs ) gulp!! Amazing. Love the usefulness of this program. And the look of main screen. Enabled me to complete my tax return finances all these years.
The registry’s date entry range that I can continue adding transactions to seems not to go past 31/12/27 ( next day is 01/01/ 1900 ) so by next year it seems I need to stop using QW 5 and start using a newer version by converting all my QDB set of files to quicken 2004 xg and then maybe 2013, already have this set up on a windows 10 Laptop running 2004 XG ( UK version) and it converts into QDF and runs perfectly ok thank goodness.

My question - is there any fix for this registry date lock to enable QW 5 to go past 31 Dec 2027. ?

or is this really the death knell date for QW5 ? I know I am clutching at straws here???
like to keep using it into 2028 for ol’ times sake I guess.
thanks Higgy

Find more posts tagged with

Quicken 2005

Comments

mshiggins

@Higgy1higgy

I suspect you are out of luck and will have to upgrade to a newer Quicken version. One of the more computer technical folks that post on these forums could probably explain the technical limitations for programs using 2 digits to store years - basically variations of the Y2K problem.

I did find a prior post asking about the same problem. Unfortunately it yielded no solutions.

https://community.quicken.com/discussion/7975789/can-i-get-quicken-5-0a-to-go-beyond-december-2026

Just curious, does Higgy stand for Higgins? If so, a fellow Higgins here.

Higgy1higgy

Hi mshiggins - thanks for yr reply. Much appreciated. No I’m a Higson but it’s similar. There are many interesting software and techie individuals on here giving answers. Hope there is one for this issue.

https://community.quicken.com/profile/10256506/Richardat71

Interesting someone else asked about getting past December 26

Chris_QPW

2027 was "a developer choice", and yes, it has to do with Y2K.

Imagine that you have the Y2K problem because you are either ~~storing or just~~ entering dates with the year being only two digits. This of course, sets up Y2K. You get to 1999 and you have a problem. Quickly changing a program so it uses 4 digits fairly major so to give you some time, you put in a workaround. You don't think anyone is going to need to put in the date 1900, so it is fine if 00 is used as 2000. And this can go for a while, but how long?

When will you get to a point where a 1900 year clashes with a 2000 year? You pick a year, anything under XX year is in the 2000s and anything over is 1900s. It looks like they picked 27. Sure, they probably could have picked an even later date, but I doubt anyone thought people would still be using the same program 27 years later.

EDIT: I crossed out storing, because I realized know how they were being stored and it isn't by "two digits". Dates are actually stored in seconds from a given date and even with the old use of a 32-bit variable that would get you to 2038 (when this problem came up operating systems and programs switched to 64-bit variables, which are good for past the possible time the universe will be around).

Chris_QPW

Oh, and I forgot to mention. Quicken 2004 XG is the last UK version. The Quicken Windows 2013 version you see mentioned on the site is US. It has multiple currency support so for the most part can be used by someone in the UK, but the conversion isn't straightforward.

Higgy1higgy

Brilliant .. and thanks so much for your explanation. So it’s a ‘hard stop’ for my trusty quicken 5a on my stalwart Dell XP then … ah well. My software developer son will be intrigued that it is so unlike C++ etc and written before he was born. Thankfully, I have the equally trusty Quicken 2004 XG . Hope it is robust enough to last a few more decades.

Chris_QPW

Actually, the original C++ would have had the same problem. The first formal standardization of C++ was in 1998, even though it existed since 1998. At the time neither C or C++ had their own "date/time", they used the "standard library" structure time_t. Over time C++ did add some of its own types and such, but C++ started out as "C with Classes".

Quicken Windows was written in C, and over time I'm sure they started using C++ and probably C# for some parts now. That is one of the things that people don't really get about Quicken and its long history, it has outlasted many changes in Windows APIs, and languages, but probably carries the "scares" of all of them.

Higgy1higgy

Again - many thanks. So much good explanation from you. My son has just explained that he programmes in milliseconds and sometimes nanosecond’s from a starting time in 1980 and bit storage could have been limited when the Y2K problem was realised so the developers had to keep it to 2027? I would need the source code of course to make any change to the date. Who has that ?

Chris_QPW

Source code isn't made available. That is the lifeblood of a software company, they aren't going to make it public. QW 5 is definitely not going to be able to be fixed.

No, both the Y2K problem and their workaround that patched QW5 were not based on a storage problem.

People tend to believe that dates in computers are stored like they see them say 31/12/27, but as I explained they aren't. There are different formats, but the one in question was stored in seconds. For Unix it was the start of 1970 and for Windows 1980. And those would still be OK till 2038 and 2048.

The Y2K problem is in fact a "human problem" not a computer problem. Notice I just wrote the date 31/12/27. Very common (provided you aren't in the US 😂), but is that 27, 2027 or maybe 1927 or 1827? People write such notation on their checks all the time and don't give it a second thought and then think that because the developers used the convention that everyone was using for their program's data entry that they might have been shortsighted.

In a nutshell, the problem in QW5 is in every dialog where you enter a date. First off, the dialog has to make sure there is enough space for typing in 2027 instead of just 27, not to mention making a guess at what 28 means if you are going to still allow two digit years entries. And the second part of what I just mentioned, you are entering text which has to be interpreted into an actual date that is then stored.

Certainly, when the time_t structure was first picked the choice of a 32-bit number over a 64-bit one was a concern, because of all number of dates you would be storing in a program like Quicken, but by the time 2000 came around it tended not to be as much as a concern and it really only needed to be fixed by 2038. In fact, they fixed it at that time by going to a 64-bit value because they weren't concerned about the space.

The reason for patching just enough to get past the Y2K problem was purely because of how much effort it was going to take to fix all the places in Quicken where it expected a two-digit year date input. Clearly, they fixed it in later years, but that would have taken some time, and they decided the 26-year workaround was fine at the time.

But this really got me thinking about when did they fix it?

QW5 means 1995, which is clearly before Y2K, so here is a question for you. When was the last patch for QW5 sent out? You might not remember or have the patch to look at its date, but one would have to assume that it was close to Y2K. And as such that would even more reinforce why they wouldn't make sweeping changes. It was already a program that was going out of the support window. Just to patch it they would have had to pull up the old source code, do that patch and send it out. That whole line of development would be deadended.

Higgy1higgy

I received the letter in the post containing a CD with an update for 2000 compliance for version 5 and 6. The date on the letter is 18 October 1999. It explains why there are sending out the update and details of the compliance standard at that time.

Higgy1higgy

after I installed this update the date format adjusted to 01/01’00 for 1st Jan 2000, the second backslash was unrecognised.

mshiggins

@Higgy1higgy good luck with your upcoming move to Q2004 XG. If you’re so inclined, post back and let us know how it goes.