Two-digit years are a problem in two places: firstly, within the actual sccs files, and secondly within command-line options. The two-digit year fields in the sccs files are correctly dealt with according to the strategy mandated by X/Open. The command-line options are also dealt with similarly.
cssc provides an additional feature for your convenience. If the
argument to the -c option of
prs contains more than twelve digits, the first two are
understood to be the century part of the year. For example,
‘971120193000’ and ‘19971120193000’ both represent exactly the
same time (7:30 p.m. on November 20, 1997). The fields of a date can be
separated with other (non-digit) characters, and so
‘1997/11/20-19:30:00’ also denotes the same time (but
‘1997/11/20’ is an error because there are fewer than twelve
Some versions of SCCS are not year 2000 compliant and write incorrect timestamps into SCCS files. cssc correctly understands the intended date, and will fix this problem when re-writing the file (see Bug-for-Bug Compatibility).
cssc represents dates internally in a way that works for Gregorian dates up to at least the year 32767 AD on all systems. Some countries didn't recognise the Gregorian calendar system until the early twentieth century but this of course is not really a problem now. The useful life of sccs is from 1969 until 2068. Years are stored in two-digit form in sccs files and so although cssc has no such limits internally, it's not possible to indicate a year outside this range in an sccs file if you want to retain compatibility with other implementations of sccs. All the cssc programs will successfully work with any date in this range, all the way up to 2068, on all systems.
In this future, years after 2068 may be represented as four-digit fields, but cssc doesn't do this yet.
The cssc test suite (see The Test Suite) contains some test files which may be useful in determining the date range with which your usual sccs implementation will cope. These are in the directory tests/year-2000.