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

Groups > comp.std.c > #6503

Re: C23: asctime is obsolescent

Show all headers | View raw

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

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 */

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