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.

The "a" in asctime() stands for American, as in ASCII as introduced in
Unix V7.

https://man.cat-v.org/unix_7th/3/ctime

--
Pete Forman

Pete Forman <petef4+usenet@gmail.com> writes:
> Keith Thompson <Keith.S.Thompson+u@gmail.com> writes:
[...]
>> 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.
>
> The "a" in asctime() stands for American, as in ASCII as introduced in
> Unix V7.
>
> https://man.cat-v.org/unix_7th/3/ctime

Yes, and all C keywords are English words, or derived from English words
or names (George Boole was English). It's not possible to avoid all
region-specific features.

asctime() (also ctime()) is clearly a legacy function using an overly
US-specific format. If the question were whether to introduce it now,
the answer would clearly be no. And the committee has already decided
to mark it as obsolescent in C23, meaning it could be removed in a later
edition. I believe C23 has been finalized, so it's no longer possible
to reverse that decision. But I expect that it will remain in the
standard for a long time.

(And I *hate* that newline at the end, but it's far too late to fix that.)

Removing it would clearly have a cost, since it would break any programs
that uses it.

--
Keith Thompson (The_Other_Keith) Keith.S.Thompson+u@gmail.com
Working, but not speaking, for XCOM Labs
void Void(void) { Void(); } /* The recursive call of the void */

Pete Forman <petef4+usenet@gmail.com> writes:
> The "a" in asctime() stands for American, as in ASCII as introduced in
> Unix V7.
>
> https://man.cat-v.org/unix_7th/3/ctime

No. The "asc" in asctime() stands for ASCII. "stands for" is not
a transitive relation.

Phil
--
We are no longer hunters and nomads. No longer awed and frightened, as we have
gained some understanding of the world in which we live. As such, we can cast
aside childish remnants from the dawn of our civilization.
-- NotSanguine on SoylentNews, after Eugen Weber in /The Western Tradition/