asctime.c

[Greg Black]

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