Path: csiph.com!news.mixmin.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: Sun, 13 Aug 2023 16:47:49 -0700 Organization: None to speak of Lines: 188 Message-ID: <87v8dimrmi.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> <87351is0i5.fsf@nosuchdomain.example.com> <865y5i8tqc.fsf@linuxsc.com> MIME-Version: 1.0 Content-Type: text/plain Injection-Info: dont-email.me; posting-host="bc618e44e086a302991f1b359b3157e4"; logging-data="2115086"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX18uheZhQSQrULbDA1u7vQwe" User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/27.2 (gnu/linux) Cancel-Lock: sha1:+PgJmsXB5r98eHuREu0qzIY9E1I= sha1:dVguq2YvP1xX5Pw6f2MIleVSi1w= Xref: csiph.com comp.std.c:6531 Tim Rentsch writes: > 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. I still don't know what you were wrong about. >>>> 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. I understand your opinion, and I disaagree. Certainly the standard can refer specifically to the ISO 8601 standard, but I see no need for the macro name to do so. The point is to define a new macro that expands to a *better* textual representation of the current date. (I could list a number of reasons why "2023-08-13" is better than "Aug 13 2023".) The fact that a particular ISO standard happens to define that representation is incidental. If including "ISO" in the name without including the ISO standard number is a problem (I don't think it is), there are alternatives. > 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. I consider the proposed "8601" in the macro name to be cruft. I don't want to add more cruft to my code to avoid it. If it were defined as __ISO_8601_DATE__, I'd just use that. __DATE__ would be perfect if it weren't already taken. The names of the existing __DATE__ and __TIME__ macros don't describe what format they use (for example, that the month name in __DATE__ is in English and the fields are in a US-centric order), because they don't need to. A new macro that expands to "2023-08-13" doesn't need to either. Users of a hypothetical new standard will read the new specification and will know what it means without having to type the standard number again every time they use it. I like the name __ISODATE__ because ISO 8601 is *the* standard that defines date formats. I don't think there would be any confusion about which ISO standard is being referenced. (__TIME__ already conforms to ISO 8601). I'd accept __YYYMMDD__, but since __DATE__ isn't going away, I'd prefer something that suggests that it's closely related to __DATE__. Perhaps "__IDATE__". -- 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 */