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

Groups > comp.std.c > #6531

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

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