Date: Mon, 2 Aug 2004 09:16:35 +0100 From: "Clive D.W. Feather" <clive@demon.net> Message-ID: <20040802081635.GD7224@finch-staff-1.thus.net> | Actually %.4d would be better. You'd prefer years with leading zeroes? Why? Year 0103 looks like someone might be playing with octal base output to me ... -- on the other hand, everyone is used to leading zeroes on minutes and seconds, as they come after the ':' usually - the 0 isn't seen as redundant, and in the hours, the leading 0 generally implies that a 24 hour clock is being used (except the time isn't late enough for it to be obvious, so we have 1am or 1pm, but 01 hours.) | This change could, in theory, break an existing program which relied on the | present specification. It could, but should there be any? The mistake that was made here was in standardising asctime/ctime at all when strftime was all that was needed. The older functions clearly have a stupid interface (for any half modern requirements) - the only reason we should be keeping them is for compatability with old code. There's no reason to do that if they're going to be changed, even slightly, from the historical definitions. And that remains true no matter how much one may be considered to be "just handling previously undefined cases". | For some value of "portable". There's "portable to all Standard C | implementations" and "portable to both Standard and pre-Standard C". There's only one definition of "portable" that matters - if I code in this particular way, can I distribute my code and assume that it will work everywhere (here that means, everywhere there's a compiler that claims to compile C code). Technical arguments about who is right, what the implementation is being compatible with, and all the rest simply don't matter. If my code fails on *any* implementations, it isn't portable. If I want my code to be portable, it has to work on everything that is able to compile it. | I'm not saying this is a hopeless cause, because this *is* clearly a case | where WG14/X3J11 messed up. But nobody has spotted this fact in 16 years | or longer, meaning it's not exactly been a major concern. That's most likely because no-one has been dealing with years outside the 1900-2140 address block very much (given that's all a 32 bit time_t can represent). Regardless of the possibility to set tm_year to just about anything, almost no-one does. It has been the recent interest in handling 64 bit time_t's that raised this issue now. kre