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:43:01 -0800 Organization: A noiseless patient Spider Lines: 52 Message-ID: <86357tgp1m.fsf@linuxsc.com> References: <875yf5ksn9.fsf@nosuchdomain.example.com> <861qocrk5b.fsf@linuxsc.com> <871qocphp0.fsf@nosuchdomain.example.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="U2FsdGVkX183FXH6jD4k6rtZ7/9CZbcHAv9geMlZJL8=" User-Agent: Gnus/5.11 (Gnus v5.11) Emacs/22.4 (gnu/linux) Cancel-Lock: sha1:b4/sE/bnaXW85CUC7bcniojLnU4= sha1:SwMEkb1ILqm0/hd8QtUoUB/Aqp8= Xref: csiph.com comp.std.c:6474 Keith Thompson writes: > Tim Rentsch writes: > >> 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__. >> >> Similar comments apply to __TIME__, which also refers to asctime(). > > I agree that __DATE__ should not be removed. On further thought, I > don't think it should be deprecated. The format it uses, "Jan 2 2023", > is too region-specific, but presumably some C code uses it, and it can't > be fully re-implemented in user code. > > If asctime() is removed in a future standard, then the descriptions of > __DATE__ and __TIME__ would have to be updated. I offer no opinion on > whether asctime() *should* be deprecated. In the absence of any compelling reason to remove it, asctime() should be retained. Sadly the people now driving the ISO C committee are hellbent for leather to "improve" the language, and will make it much worse in the process. (Just stating my opinion, in case that isn't immediately obvious.) > I don't see how "Similar comments" would apply to __TIME__. I'm not > suggesting changing it, just updating the description. > > I'm at a loss to understand why you think adding __ISODATE__ would be > pointless. If I'm going to include the compilation date in my own code, > I'd much rather use "YYYY-MM-DD" than "Mmm dd yyyy", assuming both are > available. If you prefer the latter, you can still use it. The thoughts behind my comments on __ISODATE_ were explained in my reply to Richard Damon's posting.