ml>> yes, and the point that i'm trying to make is that the
 ml>> standard time library code is at least one place that
 ml>> the fault occurs... generally, what is done is to take
 ml>> today's year and subtract the epoch [...]

 DC> As it is, I had a similar problem with dBXL(dBASE IV).

i don't doubt it at all... each language has its set of basic libraries...
video manipulation, file manipulation, time, etc... as far as i'm aware,
every implementation of the C language uses the same code or routines in
their time library... this means that they all have the exact same
problem... the same with PASCAL... the various flavors carry routines that
are basically similar in their processing...

one might wonder why this is? especially when there are newer versions
out... well, it basically comes down to backward compatibility... code is
written a certain way and expects certain results... when a curve is thrown
in and stuff is changed, then things break...

funny thing about that, too... it is exactly what caused the three digit
"two-digit year" results problem (107 instead of 07)... those who
came before didn't stop to think what their routine, which everyone uses,
would do when the result was greater than 99...

 DC>> It's a shame I can't contact the people that created OMX.
 DC>> They seemed to have guessed the Y2K deal and handled it
 DC>> before it became an issue.

 ml>> it isn't any majik, really... if one follows decent
 ml>> practises, one won't fall into traps like this... why
 ml>> would you want or need to contact the OMX folk?

 DC> I'm not quite sure, but it seems to work as a Door for BW,
 DC> albeit limited to 2 users.

welllll... kinda... not as a door, though... a door is an external program
on a bbs that users interact with... what OMX does is very simple,
though... it extracts new messages from the JAM message base and packs them
in the BW format... you read and write in BW and then the REP is processed
by OMX which puts the messages into the JAM message base... there's nothing
majikal about that...

 DC> With it, I never had the Y2K problem with BW.

actually, you did and do if you're still running BW without one of the fixes ;)

 DC> My messages prior to sending show a wrong date.

exactly... so you do still have the y2k problem...

 DC> But, OMX handles them properly when it translates them
 DC> into JAM format for sending.

this is likely due to the fact that JAM stores the dates in unix format...
that is, the number of seconds since the epoch... yes, this is the format
that runs out of positive numbers in 2038 ;)

 DC> I've never had to avail myself with Dale's REP fix.

easily understood as you've used software that worked around it and hid it ;)

)\/(ark