GD> No, it would not, but it *could* if you expanded the date formats in
 GD> MAX.CTL.  If you let your users pick the date format of their choice,
 GD> then all dates would be crystal clear.
 SD> The whole idea behind the y2k bugfix (or at least "my" idea) is to
 SD> change as little as possible to make Maximus function correctly and
 SD> behave logically when presented with y2k dates.
Great!
 SD> I agree that, in the future, having configurable 4-digit dates would
 SD> be nice. For now, however, it is not in the works.  Please see the end
 SD> of this message.
Waiting with baited breath...
 GD> There could be a help file for users that explains the chosen date
 GD> format for the particular BBS.  This help file could be generated as
 GD> MAX.CTL is compiled.
 SD> Of course, users will decide to read that as soon as they finish
 SD> reporting all of the "do not remove" mattress tags that they have
 SD> removed in their lifetimes.

 SD> Let's not forget that SILT will also have to generate this help file
 SD> in any language that can be installed on the system, so I will have to
 SD> hardcode this message in a few hundred languages.  (Again, see the end
 SD> of the message.)
Hmmm... Could be a bit of work, I guess...  Perhaps provide an example
to the sysop so he could make that help file?
 GD> True, but we were talking about "10/12/2001" before.  If that were
 GD> "10/12/84" would you still know what date it was?  I would not know for
 GD> sure 100%.  Some countries use day/month/year, others month/day/year,
 GD> Canada uses both.
 SD> If it were 10/12/01, sure, I would know.  Based on the context of my
 SD> current location, it obviously refers to October 12th, 2001.  If it
 SD> crosses national boundaries over the net, you are going to have
 SD> problems understanding the date with or without the y2k problem, so
 SD> it's not a concern.
 SD>> You indicated that Maximus HAD to follow whatever the industry did.
 GD> Why are you making this a larger issue than I intended?  All I was
 GD> talking about is year 2000 compliance, i.e. 4-digit years...
 SD> See above.  I simply wish to point out that Maximus does not *HAVE* to
 SD> do whatever the industry does.
Well, the industry hasn't decided about the order of the components of a
date field, nor its separators, at least not in the context of y2k
compliance.
 GD> As I said before, give users the choice.  Right now, there is no choice.
 SD> The bottom line is this:
 SD> The choice for multiple date formats is an extra feature, as is the
 SD> extra "date" help file and everything else.  If I add extra features,
 SD> I will probably break something.  If I add extra features, the
 SD> "bugfix" release has to be tested much more extensively.  If I add
 SD> extra features, it will take a lot longer to get this "corrective
 SD> service" release out than it would otherwise.
 SD> If I fix Maximus to support y2k dates in a 2-digit format, I don't
 SD> have to worry about breaking the screens, destroying formatting,
 SD> upsetting third-party file formats that only accept 2-digit dates, and
 SD> so on.
 SD> Perhaps you may consider this the "easy way out", but it is the path
 SD> that we plan to follow for now.
And that is your choice and I respect that.
Gerry Danen (gdanen@accessweb.com) C+Net BBS @ 403-477-9545
            http://www.geocities.com/SiliconValley/Way/9823
2 years, 72 days, 3 hours, 48 minutes, and 58 seconds until January 1, 2000.
--- Maximus 3.01
---------------