Path: csiph.com!news.mixmin.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: Mon, 02 Jan 2023 16:47:39 -0800 Organization: None to speak of Lines: 44 Message-ID: <871qocphp0.fsf@nosuchdomain.example.com> References: <875yf5ksn9.fsf@nosuchdomain.example.com> <861qocrk5b.fsf@linuxsc.com> MIME-Version: 1.0 Content-Type: text/plain Injection-Info: reader01.eternal-september.org; posting-host="a5ee6487fac100578e1eb211b538cf09"; logging-data="2029033"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX19IfzdfN7T6uffEnCfo89DO" User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/27.2 (gnu/linux) Cancel-Lock: sha1:DAuTtMUUcbVoSdRcWUOmVHFXGJI= sha1:cKdmaO1IE/3a3/suP1D2ph+4Jlk= Xref: csiph.com comp.std.c:6464 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. 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. -- 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 */