Path: csiph.com!weretis.net!feeder8.news.weretis.net!eternal-september.org!news.eternal-september.org!.POSTED!not-for-mail From: Keith Thompson Newsgroups: comp.std.c Subject: Re: C23: asctime is obsolescent Date: Thu, 20 Jul 2023 15:04:34 -0700 Organization: None to speak of Lines: 111 Message-ID: <87351is0i5.fsf@nosuchdomain.example.com> References: <875yf5ksn9.fsf@nosuchdomain.example.com> <861qocrk5b.fsf@linuxsc.com> <867cx5gpgo.fsf@linuxsc.com> <874js8j18h.fsf@nosuchdomain.example.com> <86h6pyzewi.fsf@linuxsc.com> MIME-Version: 1.0 Content-Type: text/plain Injection-Info: dont-email.me; posting-host="2370f913b850030e0527dd0f7396627d"; logging-data="3049108"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX19cjbUlZ/mgLF+DDX/lq3IY" User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/27.2 (gnu/linux) Cancel-Lock: sha1:uIJfgijkVemN01X134A94Sfo46Y= sha1:l09zEMmwEjwUd1aVMQFGDs0VbAI= Xref: csiph.com comp.std.c:6503 Tim Rentsch writes: > Keith Thompson writes: >> 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. > > To do that I would have had to have known that I was confused, > which I didn't. Are you saying that you weren't confused, or that you were confused and didn't know it? >> Do you have a suggestion for a better name? > > Yes, a more explicit one, including a numeric indicator of > which ISO standard it's from (and it's likely there is more > than one possibility). You're replying to something I wrote about six months ago. When I asked whether you have a suggestion, I was also implicitly asking what your suggestion is. Perhaps you'll let us know before the end of the year. > I consulted with someone whose job it is to ensure ISO > compliance in an industry that takes ISO compliance > seriously, and she absolutely agreed with this reaction. > These markers should ALWAYS be explicit. Ambiguity is > the enemy. I would think that you of all people would > agree with this position. Names don't have to be fully descriptive. "size_t" doesn't say that the size is measured in bytes, or that the "t" stands for "type". It doesn't have to. The meaning is specified in the standard. I already gave my reasons for not wanting the proposed new name to be "__ISO_8601_DATE__". All I'm looking for is something that's reasonably clear and distinct from "__DATE__". If such a symbol were added, the standard would have to describe its semantics precisely, with or without referring to the ISO 8601 standard. I'd also be happy with a name like "__YYYYMMDD__" or "__YMD__". -- Keith Thompson (The_Other_Keith) Keith.S.Thompson+u@gmail.com Will write code for food. void Void(void) { Void(); } /* The recursive call of the void */