It's probably worth distinguishing between the internal clock, the ability to set dates > 1999, the ability to print dates > 1999, etc. For instance, both Multics and Unix had an internal clock that ran correctly past the century end. (Although they do run out / roll over not too much later - in Multics' case, in 2039. For the Multics one, see here: http://www.multicians.org/jhs-clock.html for more.) However, in the case of Unix, both date setting and the canonical routine for date printing (separate code) didn't handle dates after 1999; for input, the year was only two digits, and for output, the first two digits were hard-coded to '19'. However, for calculating dates (which returned a vector of numbers), that part did theoretically work correctly for years after 1999 (it returned [$YEAR-1970]), but... There was a separate bug that caused the year calculation to fail in the closing months of 1999. Whether the person who wrote the code knew of the bug - it's a fairly simple one, an overflow of a short integer - I don't know, but it's possible they did, and on calculating when it would happen, decided that the fact that it would coincidentally also happen at century end meant it could be ignored at that point. However, once that was fixed, the date calcuation routine returned the correct year (without needing to change the interface). I don't know whether date input/calculation/output on Multics had similar issues: if you google "Multics leap year" it shows the source code for a couple of routines dealing with dates, but alas it's all in 645/6180 assembler, so I can't really grok it! It looks like it _might_ work, though (it seems to calculate the number of years since Multics' epoch - 1901 - and add that to 1901). If I had more time to expend, I could look at ITS too... :-( Noel