Path: csiph.com!weretis.net!feeder8.news.weretis.net!eternal-september.org!reader01.eternal-september.org!.POSTED!not-for-mail From: Tim Rentsch Newsgroups: comp.std.c Subject: Re: C23: asctime is obsolescent Date: Sun, 29 Jan 2023 10:33:59 -0800 Organization: A noiseless patient Spider Lines: 45 Message-ID: <867cx5gpgo.fsf@linuxsc.com> References: <875yf5ksn9.fsf@nosuchdomain.example.com> <861qocrk5b.fsf@linuxsc.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Injection-Info: reader01.eternal-september.org; posting-host="8ce3893f3eb724e7abcf14dabf224dec"; logging-data="3013316"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX18Uv69c5yDEZcWWtlzMVr6vI2oYqbpQjSo=" User-Agent: Gnus/5.11 (Gnus v5.11) Emacs/22.4 (gnu/linux) Cancel-Lock: sha1:j3pZki/O+N7IrVPOIqNU31jLwDg= sha1:E6Zc/OaDppL48w2vAsv/0HhpPj4= Xref: csiph.com comp.std.c:6473 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.