[tz] strange ways of processing time (was: strftime %s)

[Paul Eggert]

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.