SD>> Why does compliance mean 4-digit years? If Maximus were to support
 SD>> 2-digit years properly ("01/14/00 = January 14, 2000"), how on earth
 SD>> could that not be compliance?
 GD> Interpretation is not compliance. Compliance means there is not a single
 GD> doubt as to what 01/14/00 means.
 SD> Aye, but therein lies the rub.
 SD> Suppose that we go whole-hog and we write October the 12th, 2001 as
 SD> "10/12/2001".  Surely, that must eliminate all ambiguity, right?
No, it would not, but it *could* if you expanded the date formats in
MAX.CTL.  If you let your users pick the date format of their choice,
then all dates would be crystal clear.
 SD> Unfortunately, in the other 94.3% of the world that is not the United
 SD> States, that date would be interpreted as December the 10th, 2001.
 SD> Your Japanese callers will have to figure out if that date means
 SD> jyu-ni-gatsu jyu-nichi or jyu-gatsu jyu-ni-nichi.
 SD> Further, suppose that we decide to write it as "Oct. 12, 2001".  Does
 SD> that eliminate all doubts?  No.
 SD> How is a potential caller supposed to those that this refers to the
 SD> year 02001, rather than the year 12001 or 22001?
There could be a help file for users that explains the chosen date
format for the particular BBS.  This help file could be generated as
MAX.CTL is compiled.
 SD> This may seem absurd, since the caller obviously has to infer that a
 SD> date is unlikely to be dated 10,000 years in the future.  This does
 SD> not seem to be too hard to grasp.
 SD> Similarly, it does not take too many brain cells to figure out that a
 SD> file was placed on your system in the year 2001 instead of 1901 or
 SD> 2101.
 SD> You complain of ambiguity... but please remember that people have been
 SD> using two-digit dates for at least the last eighty-seven years without
 SD> complaints. Two billion people can't all be wrong (except when it
 SD> comes to McDonald's).
87?
 SD> The last time I checked, some computer programs may produce wrong
 SD> answers in the year 2000, but the "common sense" portion of the
 SD> average person's brain is not going to implode just because the
 SD> millenium digit happens to flip over.
I agree.
 SD> If I see something dated "01/01/84", I know exactly when it was made
 SD> by context.  That understanding is not going to change in the next
 SD> 2.13 years.
True, but we were talking about "10/12/2001" before.  If that were
"10/12/84" would you still know what date it was?  I would not know for
sure 100%.  Some countries use day/month/year, others month/day/year,
Canada uses both.
 GD> The separator character has nothing to do with compliance.  You have an
 SD> You indicated that Maximus HAD to follow whatever the industry did.
 SD> If the industry decides to ban dashes, why should Maximus follow that?
 SD> The computer industry has, in hindsight, done a lot of stupid things
 SD> (ISA, EMS, segment:offset, the packed date format in DOS, ad nauseum).
 SD>> As long as date handling is internally consistent and an intuitive way
 SD>> to do things, who cares what the rest of the industry does?
Why are you making this a larger issue than I intended?  All I was
talking about is year 2000 compliance, i.e. 4-digit years...
 GD> Not to insult you, but I think that's a pretty narrow-minded view.
 SD> When the three little piggies went to build their houses, and Puff the
 SD> Magic Dragon came to blow them all down, it was only Winnie the Pooh's
 SD> house which remained standing because he decided to build it out of
 SD> something else.  I think it's pretty narrow-minded if you only do what
 SD> everyone else is doing.
I think you should brush up on your fairy tales... 
 SD> If Maximus forces everyone to enter "01/03/2002", I can guarantee
 SD> that, a little over three years from now, I am going to get flamed a
 SD> little bit because users are bruising their pinkies when typing those
 SD> two extra digits.  Thirteen years from now, I can guarantee that I
 SD> will get flamed en masse.  What's the point in writing "01/03/2010"
 SD> when you can just write "01/03/10"?
As I said before, give users the choice.  Right now, there is no choice.
 GD> But that's the problem.  In some cases a 2-digit year is ambiguous and
 GD> in others it's not.  So why not strive for consistency and unambiguouty
 GD> in *all* cases?
 SD> If we are consistent and display "January the 1st, MCMXCIIIX A.D." for
 SD> each and every file on the system, there won't be enough space left
 SD> for the filename (let alone the description).
No comment.
 GD> are cheap these days. Take the following log extract for example
 GD>   + 12 Oct 11:03:01 MAX  Begin, v3.01 (task=1)
 SD> Of course, Maximus only uses this log file format for historical
 SD> reasons.  I suppose that we could change the log, but it would break
 SD> lots of other programs.
Again, that could be a user option.
 SD> PS: As you may have guessed, when I was in grade school, I got about
 SD> the same mark on both the "Fairy Tales" and the "Roman Numerals"
 SD> units...

Gerry Danen (gdanen@accessweb.com) C+Net BBS @ 403-477-9545
            http://www.geocities.com/SiliconValley/Way/9823
2 years, 76 days, 17 hours, 42 minutes, and 21 seconds until January 1, 2000.
--- Maximus 3.01
 # Origin: C+Net BBS. Programming & Networking. (111:1403/2)
---------------