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


Groups > comp.std.c > #6474

Re: C23: asctime is obsolescent

From Tim Rentsch <tr.17687@z991.linuxsc.com>
Newsgroups comp.std.c
Subject Re: C23: asctime is obsolescent
Date 2023-01-29 10:43 -0800
Organization A noiseless patient Spider
Message-ID <86357tgp1m.fsf@linuxsc.com> (permalink)
References <875yf5ksn9.fsf@nosuchdomain.example.com> <861qocrk5b.fsf@linuxsc.com> <871qocphp0.fsf@nosuchdomain.example.com>

Show all headers | View raw


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:
>>
>>> 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__.
>>
>> Similar comments apply to __TIME__, which also refers to asctime().
>
> I agree that __DATE__ should not be removed.  On further thought, I
> don't think it should be deprecated.  The format it uses, "Jan  2 2023",
> is too region-specific, but presumably some C code uses it, and it can't
> be fully re-implemented in user code.
>
> If asctime() is removed in a future standard, then the descriptions of
> __DATE__ and __TIME__ would have to be updated.  I offer no opinion on
> whether asctime() *should* be deprecated.

In the absence of any compelling reason to remove it, asctime()
should be retained.  Sadly the people now driving the ISO C
committee are hellbent for leather to "improve" the language,
and will make it much worse in the process.  (Just stating my
opinion, in case that isn't immediately obvious.)

> I don't see how "Similar comments" would apply to __TIME__.  I'm not
> suggesting changing it, just updating the description.
>
> I'm at a loss to understand why you think adding __ISODATE__ would be
> pointless.  If I'm going to include the compilation date in my own code,
> I'd much rather use "YYYY-MM-DD" than "Mmm dd yyyy", assuming both are
> available.  If you prefer the latter, you can still use it.

The thoughts behind my comments on __ISODATE_ were explained
in my reply to Richard Damon's posting.

Back to comp.std.c | Previous | NextPrevious 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