Autor: John Jetmore Data: A: exim-users Assumpte: Re: [Exim] compile date format issue
On Thu, 20 Mar 2003, Philip Hazel wrote:
> > Output of printf("date = %s\n", __DATE__) is '03/19/03'
>
> Confusing, incomplete, and ambiguous! The '19' gives some of it away,
> but consider '03/11/03': is that y/m/d, y/d/m, m/d/y, or d/m/y? In this
> international age, that is a really stupid way to write a date, IMHO.
>
> I imagine that most people reading this list are aware that the
> European habit is to write d/m/y, while the US habit is m/d/y. I believe
> that that should rule out the use of this kind of format for anything
> that is likely to be seen outside the immediate locality.
The weird thing is that the MacOSX GUI is completely locale-aware. It
strikes me as really odd that they would have gone out of their way to
break it here. I can't image they've hooked those locale settings
into gcc, though they've done stranger things.
I've never particularly understood why we write the date that way, either,
though I admit to dating my checks that way. Everything computer related,
though, is YYYYMMDD. Much nicer to parse...
> AHA! You have a bug in your compiler. I have consulted my ancient copy
> of the original ANSI C standard. It clearly says that the value of
> __DATE__ is a string of the form "Mmm dd yyyy".
Hmm... I tried to find an online reference for that last night and was
unable. The closest I found was a page on gcc.gnu.org which stated
that __DATE__ was supposed to be replaced by the date. It also had a
reference number which was probably to a section of the standard, but I
never traced it down. If I had found it was against standard I wouldn't
have reported it here (except perhaps as an oddity).
> Given the content of the C standard, I don't think I'm inclined to
> accept a patch...
yeah. OK, off to see if this has been reported as a bug to Apple...