On 2024-01-15 09:10, Clive D.W. Feather via tz wrote:
I have mercifully forgotten the exact code, but it was along the lines of:
sprintf (buffer, "19%s%s", int_to_str (tm_year / 10), int_to_str (tm_year % 10));
Yeowch! Contrast to 7th Edition Unix, which despite being written in the 1970s had few Y2K issues (though of course it had a huge Y2038 issue!). I just did a quick scan of 7th Edition source code and found only "at", "date", and "troff" assuming two-digit years. (Of course I may have missed some bugs.) My guess is that 7th Edition Unix was largely Y2k-safe because much of its source code predated localtime, and simply called ctime and grabbed text from the result. ctime's simple API, which always supplied a full year, made Y2k bugs less likely. Conversely, that same API had serious problems once time_t grew enough to support years before 1000 or past 9999, which is partly why it's now obsolete. PS. 7th edition's implementation of asctime did have this amusing bit of code: if (t->tm_year>=100) { cp[1] = '2'; cp[2] = '0'; } and this was not a bug! Before it's executed cp[1]=='1' and cp[2]=='9', and on the 32-bit time_t platforms that 7th Edition ran on, "19" and "20" were the only possibilities for century digits.