Mailing List Message #101788
From: Tom Rymes <>
Subject: Re: Calendar and dates before 1.1.1971
Date: Tue, 29 Mar 2011 10:20:05 -0400
To: CommuniGate Pro Discussions <>
On 03/28/2011 5:48 PM, Support@ish wrote:
They probably do not consider it a bug, so I doubt they will. Just like
I do not consider it a bug. Just a limitation.

There are many limitations that you live with in the computing world,
32bit OS < 4gb of RAM, for an example. You lived with that for years,
was that also a bug? Who is going to fix your 32x OS < 4gb of RAM bug?
You could use PAE I suppose.

Good luck.

This is accurate, but it misses the point. Yes, it's a limitation, not a bug. However, it is a limitation that causes unexpected and undesirable behavior from the point of view of most users. Users (and many client programs) use the actual birth year in the event because it is simpler and more elegant than any other proposed solution. By looking at the start date, you can determine in exactly what year the person was born. If some other value is used (1971 or the year the event was created), the only thing you know by looking at the information is that it MIGHT be accurate. It might not.

Moreover, it is a limitation that few, if any, competitors to CGP share. THis means that is APPEARS to be a bug from the point of view of most users, including the management types who approve the purchase of CGP or its replacement, and they almost certainly have no idea what a unix time-stamp is.

Further, the unix time-stamp is an explanation, not a valid excuse. It explains why this is so, but it does not make it acceptable. To use your 32-bit OS analogy, if all of your competitors are also 32-bit and they all share the limitation, then it's a valid excuse. If you are the only remaining 32-bit OS and none of your competitors share that limitation, it's no-longer valid because there is a proven way to work around the limitation. More importantly, it means that that limitation makes your product look bad when compared to your competitors.

If anyone thinks that the average corporate president of a CGP customer wouldn't use the birth-year as the start date when entering a birthday, think again. If anyone thinks that President won't be annoyed when he realizes that he has no idea when "Big Customer's CEO's Daughter" was born because CGP decided 1971 was better than the year he entered, think again. If anyone thinks that President won't have something against CGP when it comes time to renew the contract or consider switching to another product, think again. This is true for ISP customers, too, as the person in question will be the president of one of your customers.

OK, my $0.02,


PS: The part of this behavior that actually IS a BUG is that the system changes the date that the user specified without notifying or asking the user's permission. I understand that there is a limitation, and I understand that CGS might choose not to fix it. It is, however, UTTERLY UNACCEPTABLE that a piece of software will change a piece of data input by a user without notifying that user in some way. "Error: Dates before 1971 are not supported" or "Notice: The start year for this event has been moved from 1969 to 1971 due to limitations in the calendar program" is the minimum acceptable.

Before anyone claims that CGS has no way of doing this because they don't know what client you are using, I submit that CGP sends me an e-mail when an event is approaching, so they can at least send an e-mail.
Subscribe (FEED) Subscribe (DIGEST) Subscribe (INDEX) Unsubscribe Mail to Listmaster