On 2004-08-05, Robert Elz wrote: [ Paraphrased: asctime was always stupid, but consistent; new code should have avoided it once we had strftime; we only offer it now for old code that was happy with its hopeless design; there's no excuse for breaking that old code since new code will always use strftime. ] This is a no-brainer; kre is right.
I can kind of live with ado's last suggested patch around this issue, though I would really much prefer there was no #if to generate the "standards conforming" version of asctime. Simply existing that way does no harm, the problem is that someone might not understand what is happening, and believe that turning on that behaviour is actually the better choice to make. If that happens and the resulting code gets distributed anywhere, then asctime has just turned into yet another of those "any code that uses this is broken by definition" functions that we (unfortunately) have too many of already.
So, I'd prefer just the "always fixed width field" version of asctime, the way the old interface was defined - I'd prefer it generate "YYYY" for the year field than "10000" (or anything else) - as long as it remains 4 characters wide - always.
Exactly. This is the only sane solution. We don't need to "fix" asctime; we just need to maintain it. Software that wanders outside its domain will eventually have to be fixed to use strftime, and that's something that will be done when the authors need to do it. The thing that should be added to asctime and friends is a note in the man pages that they are not intended for new code and are provided for historical compatibility; and that new code should be looking at strftime. The stuff that usually appears about standards conformance does rather give the impression to people who stumble across this stuff that it's somehow blessed. It's not; it was always cursed; it should stay that way. Greg