Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.std.c > #6500

Re: C23: asctime is obsolescent

Show all headers | View raw

Keith Thompson <Keith.S.Thompson+u@gmail.com> writes:

> Tim Rentsch <tr.17687@z991.linuxsc.com> writes:
>
>> 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.
>
> 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.

> 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).

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.

Back to comp.std.c | Previous | Next — Previous in thread | Next in thread | Find similar

Thread

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