Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
| Path | csiph.com!weretis.net!feeder8.news.weretis.net!eternal-september.org!reader01.eternal-september.org!.POSTED!not-for-mail |
|---|---|
| From | Tim Rentsch <tr.17687@z991.linuxsc.com> |
| 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> (permalink) |
| References | <875yf5ksn9.fsf@nosuchdomain.example.com> <861qocrk5b.fsf@linuxsc.com> <IeEsL.27470$cKvc.4521@fx42.iad> |
| 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 |
Show key headers only | View raw
Richard Damon <Richard@Damon-Family.org> writes: > On 1/2/23 11:11 AM, Tim Rentsch wrote: > >> Keith Thompson <Keith.S.Thompson+u@gmail.com> 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.
Back to comp.std.c | Previous | Next — Previous in thread | Next in thread | Find similar
C23: asctime is obsolescent Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2022-11-23 18:12 -0800
Re: C23: asctime is obsolescent Tim Rentsch <tr.17687@z991.linuxsc.com> - 2023-01-02 08:11 -0800
Re: C23: asctime is obsolescent Richard Damon <Richard@Damon-Family.org> - 2023-01-02 12:11 -0500
Re: C23: asctime is obsolescent Tim Rentsch <tr.17687@z991.linuxsc.com> - 2023-01-29 10:33 -0800
Re: C23: asctime is obsolescent Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2023-01-29 16:49 -0800
Re: C23: asctime is obsolescent Pete Forman <petef4+usenet@gmail.com> - 2023-01-30 23:23 +0000
Re: C23: asctime is obsolescent Tim Rentsch <tr.17687@z991.linuxsc.com> - 2023-07-20 10:11 -0700
Re: C23: asctime is obsolescent Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2023-07-20 15:04 -0700
Re: C23: asctime is obsolescent Tim Rentsch <tr.17687@z991.linuxsc.com> - 2023-08-13 15:26 -0700
Re: C23: asctime is obsolescent Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2023-08-13 16:47 -0700
Re: C23: asctime is obsolescent Jakob Bohm <jb-usenet@wisemo.com.invalid> - 2023-08-17 21:18 +0200
Re: C23: asctime is obsolescent Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2023-08-17 13:14 -0700
Re: C23: asctime is obsolescent Jakob Bohm <jb-usenet@wisemo.com.invalid> - 2023-08-18 01:26 +0200
Re: C23: asctime is obsolescent Pete Forman <petef4+usenet@gmail.com> - 2023-08-21 17:42 +0100
Re: C23: asctime is obsolescent Tim Rentsch <tr.17687@z991.linuxsc.com> - 2023-08-29 02:37 -0700
Re: C23: asctime is obsolescent Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2023-01-02 16:47 -0800
Re: C23: asctime is obsolescent David Brown <david.brown@hesbynett.no> - 2023-01-03 09:40 +0100
Re: C23: asctime is obsolescent Pete Forman <petef4+usenet@gmail.com> - 2023-01-03 15:15 +0000
Re: C23: asctime is obsolescent Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2023-01-03 10:35 -0800
Re: C23: asctime is obsolescent Phil Carmody <pc+usenet@asdf.org> - 2023-01-04 18:22 +0200
Re: C23: asctime is obsolescent James Kuyper <jameskuyper@alumni.caltech.edu> - 2023-01-04 15:04 -0500
Re: C23: asctime is obsolescent Tim Rentsch <tr.17687@z991.linuxsc.com> - 2023-01-29 10:43 -0800
Re: C23: asctime is obsolescent Tim Rentsch <tr.17687@z991.linuxsc.com> - 2023-01-02 08:20 -0800
Re: C23: asctime is obsolescent Kaz Kylheku <864-117-4973@kylheku.com> - 2023-07-20 17:29 +0000
Re: C23: asctime is obsolescent Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2023-07-20 15:20 -0700
csiph-web