Question: Why was the particular character representation that the `asctime` function returns, i.e. `Www Mmm dd hh:mm:ss yyyy\n`, chosen and what is its origin? The ordering of the information seems peculiar to me, especially putting the time information in between the date information. Is this (or was this) a common datetime representation in the US?

Answer: 
This come directly from C. Probably the year was added later. Also the `\n` is strange. Probably a convenience function when building UNIX, and it got standardized by use.

Note: the function is "obsolete", and possibly it will be removed in later version of C. It is replaced by more powerful `strftime()`.

[POSIX](http://pubs.opengroup.org/onlinepubs/9699919799/functions/asctime.html) has no rationale about the choice.

[ESR](http://www.catb.org/esr/time-programming/) wrote:

> 
> In older Unixes the following functions were available to report time and date as a string. They wired in bad design choices (the date string is of unpredictable length and includes a trailing "\n"), are not locale-aware, and have undefined behavior for years before 0 or after 9999.
> 
> 
> 

We have also few information from 7th edition of the manual (1979) [see manual pages](https://s3.amazonaws.com/plan9-bell-labs/7thEdMan/vol1/man3.bun.txt).

[Somebody (Clive D.W. Feather)](https://mm.icann.org/pipermail/tz/2004-July/012564.html) looked for the same information as you (but directly to C standard group), but I do not find the answer. Just that C99 were corrected because some imprecision [email on the same thread](https://mm.icann.org/pipermail/tz/2004-August/012580.html).

I think it will be difficult to get more information.
It's not a common representation in the US, and the C Rationale even admits as much:

> 
> **7.11 Localization** 
> 
> 
> ....
> 
> 
> **Date and time.** The standard function `asctime` returns a string which
>  includes abbreviations for month and weekday names, and returns the
>  various elements in a format which might be considered unusual even
>  in its country of origin.
> 
> 
> 

In hindsight, it's one of those functions that never should have made it into a Standard. The lack of a Rationale justifying its inclusion is a clear sign of that.