Path: csiph.com!weretis.net!feeder8.news.weretis.net!eternal-september.org!reader01.eternal-september.org!.POSTED!not-for-mail From: Keith Thompson Newsgroups: comp.std.c Subject: Re: C23: asctime is obsolescent Date: Sun, 29 Jan 2023 16:49:02 -0800 Organization: None to speak of Lines: 73 Message-ID: <874js8j18h.fsf@nosuchdomain.example.com> References: <875yf5ksn9.fsf@nosuchdomain.example.com> <861qocrk5b.fsf@linuxsc.com> <867cx5gpgo.fsf@linuxsc.com> MIME-Version: 1.0 Content-Type: text/plain Injection-Info: reader01.eternal-september.org; posting-host="5de04f3beba53446e2ae138ac4f28f9a"; logging-data="3150338"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX18GdbDm4ELF57kBycgxizK4" User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/27.2 (gnu/linux) Cancel-Lock: sha1:EpCFkylhfIvtZDVi3IE5//go2fE= sha1:jZnW+B2r/g06+yZRbaTmcXP0b4Q= Xref: csiph.com comp.std.c:6478 Tim Rentsch writes: > Richard Damon writes: >> On 1/2/23 11:11 AM, Tim Rentsch wrote: >>> Keith Thompson writes: >>>> In the latest C23 draft: >>>> https://www.open-std.org/jtc1/sc22/wg14/www/docs/n3047.pdf >>>> the descriptions of the __DATE__ and __TIME__ macros refer to the >>>> asctime() function. >>>> >>>> That's not new. What's new is that asctime() is deprecated. >>>> >>>> Referring to a deprecated function isn't really a problem, but if >>>> asctime() is actually removed in a future standard the descriptions of >>>> __DATE__ and __TIME__ will need to be updated. >>>> >>>> It would also be nice to have a new macro that expands to the current >>>> date in the form "YYYY-MM-DD". I do not suggest changing the behavior >>>> of __DATE__, but perhaps something like __ISODATE__ could be added. >>>> Question: If this is done, should __DATE__ be deprecated? >>> >>> It seems pointless to add __ISODATE__ if __DATE__ is retained, and >>> worse than pointless to add __ISODATE__ and then remove __DATE__. >> >> Why? What is wrong with having macros to get a value in different >> formats. Different applications may well want either one. > > To my way of thinking, the symbol __DATE__ is defined in an ISO > document, so it already qualifies as an ISO date. To have > another symbol named __ISODATE__ is redundant if it means the > same thing as __DATE__, or confusing if it means something > different. If it's important to have a symbol for a different > format defined in some other ISO standard, the symbol name should > include some indication of where the format comes from, in a > similar manner to __STDC_IEC_559__, for example. > >> Almost all my programs currently use __DATE__ (and __TIME__) to embed >> build information into the program. I could see applications where >> having the ISO formatted date would be useful, as it has some very >> useful properties (like sortability) > > I'm okay with having another date format. I just don't think the > symbol that gives it should be named __ISODATE__, because that's > confusing. The format is from ISO 8601, but I would oppose calling the new macro __ISO_8601_DATE__, because longer and more difficult to remember. My intent is to provide an *easy* way to embed the compilation date as a string in an executable in a reasonable format. Inserting "_8601_" into the name doesn't add sufficient value, and __ISODATE__ is sufficiently clear. And it's perfectly possible for the C standard to refer to a YYYY-MM-DD format without mentioning the ISO 8601 standard. The only reason to keep the current __DATE__ in the standard is backward compatibility (and yes, that's an *extremely* compelling reason). If I were adding this to a new language, there would just be a __DATE__ macro that expands to "YYYY-MM-DD"; it would never occur to me to build something into the language that expands to "Mmm DD YYYY". Adding "ISO" to the new name is a concession to backward compatibility. Not every name has to describe its origin, and nobody seeing the name __ISODATE__ is going to think that the ISO standard it refers to is the ISO C standard. I disagree with your assertion that it would be confusing. And if your problem with the name __ISODATE__ is the "ISO" is confusing, you could have said that in the first place. Do you have a suggestion for a better name? -- Keith Thompson (The_Other_Keith) Keith.S.Thompson+u@gmail.com Working, but not speaking, for XCOM Labs void Void(void) { Void(); } /* The recursive call of the void */