Path: csiph.com!news.mixmin.net!eternal-september.org!news.eternal-september.org!.POSTED!not-for-mail From: Tim Rentsch Newsgroups: comp.std.c Subject: Re: C23: asctime is obsolescent Date: Sun, 13 Aug 2023 15:26:03 -0700 Organization: A noiseless patient Spider Lines: 154 Message-ID: <865y5i8tqc.fsf@linuxsc.com> References: <875yf5ksn9.fsf@nosuchdomain.example.com> <861qocrk5b.fsf@linuxsc.com> <867cx5gpgo.fsf@linuxsc.com> <874js8j18h.fsf@nosuchdomain.example.com> <86h6pyzewi.fsf@linuxsc.com> <87351is0i5.fsf@nosuchdomain.example.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Injection-Info: dont-email.me; posting-host="43370f569e8ab1d7fa987214319e42b9"; logging-data="2098105"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX1+K6zWfDrcT10ltup5LgXaWN/0IbxdBo0Q=" User-Agent: Gnus/5.11 (Gnus v5.11) Emacs/22.4 (gnu/linux) Cancel-Lock: sha1:bmx3ow+GccAndIvWECw+wbZiqYc= sha1:XCfMMVrOGorTy9EX26XDUpqERTA= Xref: csiph.com comp.std.c:6530 Keith Thompson writes: > 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? I wasn't confused. I was wrong, but I wasn't confused. >>> 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. Yes, I'm sorry it took so long. It's been a hard year. > 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 already gave a suggestion. I don't at this moment have enough information to make that suggestion more specific. >> 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. This case is one where I believe it would be prudent for the particular ISO reference to be explicit in the name, and not just given indirectly in text in the C 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__". Yes, I think I understand your reasoning. I don't share your conclusions, as I have tried to explain. > If such a symbol were added, the standard would have to > describe its semantics precisely, with or without referring to > the ISO 8601 standard. If the generated date string is meant to conform to a particular format defined in an ISO standard, then it seems like good practice would dictate that a reference to the specific ISO standard document should be given in the C standard, and also listed as a normative reference. > I'd also be happy with a name like "__YYYYMMDD__" or "__YMD__". If the point, or at least part of the point, is to present a date in a format that conforms to one given in an ISO standard, then it seems a good idea to make that apparent in the name. In this very particular case, more explicit is better. And there is nothing stopping someone from using a #define'd symbol #define DATE_YYYYMMDD __ISO_8601_DATE__ if they want to use a name that is more directly descriptive and perhaps easier to remember.