SCCS question

[Gary Singleton]

I'm posting this for a friend of mine who does not have usenet access.
Please respond to singleto at evax.uta.edu or to usenet.  Thanks.

SCCS and RCS both seem to have a couple of bugs concerning their use
of dates and times.

First, a discussion of times.
SCCS stores delta times in `HH:MM:SS' form,
and RCS stores times in `HH.MM.SS' form.
While they do handle the 24-hour time rather well,
they fail to account for the time zone.
Thus, if I am using SCCS or RCS
on a networked system that spans more than one time zone,
I could get into serious trouble
attempting to track the exact time that deltas are made.
SCCS can't deal with deltas with a time in the `future',
which would occur if user bob made a delta in the EST zone
and user ray then immediately checking out that delta for read only
in the CST time zone.
Part of this problem can be alleviated by executing remote commands,
such that all SCCS/RCS commands are executed on a single machine,
but this doesn't solve the problem if a networked file system
(like NFS) is used instead.

Second, a discussion of dates.
SCCS stores delta dates in `YY/MM/DD' form,
and RCS stores dates in `YY.MM.DD' form.
This is obviously going to be a problem after 31-Dec-1999
(which isn't far off),
because only the last two digits of the year are stored.
RCS doesn't seem to care what the the digits are
(allowing the full range of years from 00 to 99),
but SCCS dislikes year numbers less than 70.
(Remember that 01-Jan-1970 is the `zero' day of the current Unix era,
as encoded in the 32-bit signed integer time_t type).

Our projects are currently built on top of SCCS,
and we deal with the time zone problem by having all delta
times made relative to the UTC (Universal Time) zone.
It's sometimes a pain to convert between UTC and local time,
but it will save our necks when we need to deal with multiple
time zones in the future.

The two-digit year problem, however, doesn't seem to have a solution,
short of rewriting SCCS (which is not an option for us on all of
the platforms we support).
Some of our version control scripts deal with this problem
by assuming that a year number
of 70 to 99 represents 1970 to 1999
and a year number
of 00 to 69 represents 2000 to 2069.
However, this will not save us from the inevitable
failure of SCCS when the new millennium rolls in.
RCS is less prone to failure, since it doesn't care what the year
number is,
but we still have to interpret year numbers 00 to 69 differently,
so that sorting deltas by date and time is (will be) done correctly.

The point of this whole diatribe is to ask the question:
will SCCS/RCS be fixed to deal with four-digit years any time soon,
(say, before 1999)?
Will SCCS/RCS be enhanced to deal with different time zones?
If so, how will the changes affect existing SCCS/RCS files?

This leads to another question:
when Unix runs out of seconds to represent in the time_t type
(which is sometime in 2038),
will the Unix era be changed?
Or is is assumed that by then Unix will be replaced by another operating
system that can deal with it?
What about archived files that (will) have old date stamps on them?

Needless to say,
there will be a lot of migration programmers employed by the end of 1999.