GoldMine Time Bomb Triggered in 2011

When I started GoldMine 6.5 for the first time in 2011, I was greeted with a rather unwelcome message:  “Please note that your computer’s system date is erroneously set to 1/1/2011. GoldMine’s synchronization may not function properly unless the system date is set correct. Would you like to correct the system’s date now?” If you press Yes, the Date and Time Properties open so you can change the date. But the date is correct!

Today I found a relevant and very helpful thread on FrontRange Connect. I’ll highlight some posts in that thread and add a few thoughts.

Note:  dates in this post are in MM/DD/YYYY format.

Where Did That Message Come From?

I found this in the release notes for GoldMine 4.00.9626, dated July 1, 1999:

“New:  GoldMine now checks for a reasonable system date (03/01/1999 – 01/01/2011) upon startup, warning users if there is a problem.”

So apparently we have now reached the end of reasonable dates for using GoldMine 4.0. However the check was not removed until much later—according to PaulRogers001’s post on 1/3/2011, the error message persists through version 7.0.3 (build 7.00.60526, release notes updated June 5, 2006).

Will Synchronization Work?

If you respond No to the message, you can continue using GoldMine without apparent issues. You can even use a hex editor to change gmw6.exe and suppress the message (in the same thread, see Aharry’s post on 1/4/2011). But that leaves the question, is there really a risk that synchronization will no longer work?

On 1/3/2011, ptools1 posted an “informal, non-official, non-binding” response from an email exchange with FrontRange support:

This seems to only be an issue with our Goldmine 6.7 and lower. We have not a fix for this issue but it has been sent to development to review. As this is a version that is no longer supported I find it unlikely that we will be release a patch.

The error message I know mentions that is may cause issues with syncing, but thorough testing shows that everything is working as designed, by clicking yes (sic) to the error message you will continue to have full range of the product.

Well that’s encouraging, but I’ll feel better if I check a few more things.

Old RecID vs. New RecID

I wondered if there was some relation to the conversion to the “New RecID”, but that was introduced with 4.0.811 on August 14, 1998, almost a year before this date warning was added. After reading a detailed explanation of the RecID change, it seems that change pertains strictly to eliminating special characters from the sorted fields in the sync tables. Dates are not mentioned.

AccountNo as Date

The first six characters the the Contact1.AccountNo field store the date the record was created, e.g. 991229 for a record created 12/29/1999. However, a quick check of my database (Lookup > Indexed Fields > Account No) shows that GoldMine switched to letters in 2000, e.g. A00105 for a record created 01/05/2000, A91215 for 12/15/2009. Starting in 2010, AccountNo’s begin with “B”; my most recent record starts with B10106 for 01/06/2011. With one letter per decade, that should be good for another 249 years or so.

The GoldMine SyncStamp

In my opinion, the real potential for a date limit is in the synchronization data. GoldMine 6.5 stores most sync data in two tables, ContTLog (for data specific to a contact database) and GMTLog (for “GMBase” data generic to all contact databases). Both of these tables have the same structure:

SYNCSTAMP	Char	7
LOGSTAMP	Char	7
ACTION	Char	2
TABLEID	Char	1
FRECID	Char	15
FIELDNAME	Char	10
USERID	Char	0

It’s the SyncStamp and LogStamp fields that concern me. Each of these compresses a date and time, down to the second, into only seven characters. According to an old INI-files.doc document I unearthed, a SyncStamp also comprises the first seven characters of the record’s unique RecID. So is there some concrete date limit on how far into the future a SyncStamp can go?

I have an old copy of SyncSpy, not the one included in GoldMine, but standalone version 1.09.2099 from 1998. In this version, if you select File > Stamp Converter, you can convert arbitrary dates to SyncStamps and back. Assuming the SyncStamp algorithm hasn’t changed, this should be a good way to check some dates and make sure GoldMine can handle them.

The first test looks good:  my newest record was created 01/06/2011, which gives a SyncStamp of F8EI4RE.

It appears that SyncStamps are chronological when sorted alphabetically. How far forward (and backward) can we go? (SyncStamps are in the format YYYYMMDD:HH:MM:SS.)

0000000	19891231:16:00:00
YTTTTTT	20380118:06:06:21
YTTVVVV	20380118:06:38:21
YTUVVVV	20380118:15:58:13
YTUZZZZ	20380118:17:02:12
YTV8HDR	20380118:19:14:07	greatest value that does not generate an error
YTV8HDS	<error>

So it would appear that SyncStamps can accommodate dates from 12/31/1989 to 01/18/2038. But what about the reverse?

20380118:19:14:07	0000000	uh oh, it’s not showing an error, but it’s not converting back to a reasonable SyncStamp
20380118:11:14:07	YTUDM8E	greatest value that does not return 000000
20380118:11:14:08	0000000	first value that returns 000000

Let’s step down through some more likely dates, July 1st at 3pm in different years:

20110701:15:00:00	FKZ9BK0
20120701:15:00:00	GB4M7K0
20150701:15:00:00	IHCZ3K0
20200701:15:00:00	M3W1RK0
20300701:15:00:00	TCT1WW0

That all looks pretty reasonable. It would appear that SyncStamps can handle dates into the 2030s.

Update 01/13/2011:  Wikipedia’s article on the Year 2038 problem, although it doesn’t mention RecIDs, would seem to confirm the 2038 boundary. Thanks to Darren Lawrence’s post today.

Update 12/29/2012:  According to this thread, a sync stamp is “the number of seconds from 01/01/1990 till the creation of the new record + the GMT in seconds.” The thread includes Basic and SQL code for converting sync stamps to the date and time. Haven’t tested this myself, but it could be an interesting starting point if you want to code your own sync stamp converter.

Conclusion

Apparently, the check for a reasonable system date added 22 12 years ago was meant merely to warn you that an incorrect system date can confuse synchronization. That’s still true today. (I would not be surprised if a user had called support because their system date was way off and it was messing up their synchronization. Didn’t computers used to default to 1/1/1900 if the CMOS battery died?)

In any case, as best as I can tell, the warning message is not an indication that synchronization will no longer work after January 1, 2011. However, I’m just an end user trying to guess at this by examining the system. It would still be helpful if FrontRange would check the code and officially confirm that even their older products will continue to work for years to come.