On 2022-11-24, Keith Thompson <Keith.S.Thompson+u@gmail.com> wrote:
> 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.

This seems like a minor oversight. __DATE__ and __TIME__ do not
depened on the semantics of asctime in any deep way; just that
__DATE__ produces a "Mmm dd yyyy" time in the same way that
asciitime would generate those fields, and similarly for __TIME__'s
"hh:mm:ss".

The documentation could refer to specific conversion specifiers of
strftime. __DATE__'s "Mmm dd yyyy" corresponds to "%b %d %Y".

The minor oversight points at a possible process problem though; it
seems that someone carelessly deprecated a function without searching
the document for occurrences of that name, and doing something about it,
resulting in requirements of a non-obsolescent feature being described
with the help of an obsolescent feature.

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

How about:

__DATEF("%Y-%M-%d")

Let's nuke trailing underscores Two leading underscores give us the
needed namespace privacy. Or just _DATEF, for that matter.

> Question: If this is done, should __DATE__ be deprecated?

Deprecating safe features used in countless code bases doesn't seem very
productive; it's just disruptive.

--
TXR Programming Language: http://nongnu.org/txr
Cygnal: Cygwin Native Application Library: http://kylheku.com/cygnal
Mastodon: @Kazinator@mstdn.ca

Kaz Kylheku <864-117-4973@kylheku.com> writes:
> On 2022-11-24, Keith Thompson <Keith.S.Thompson+u@gmail.com> wrote:
>> 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.
>
> This seems like a minor oversight. __DATE__ and __TIME__ do not
> depened on the semantics of asctime in any deep way; just that
> __DATE__ produces a "Mmm dd yyyy" time in the same way that
> asciitime would generate those fields, and similarly for __TIME__'s
> "hh:mm:ss".
>
> The documentation could refer to specific conversion specifiers of
> strftime. __DATE__'s "Mmm dd yyyy" corresponds to "%b %d %Y".

I like it.

> The minor oversight points at a possible process problem though; it
> seems that someone carelessly deprecated a function without searching
> the document for occurrences of that name, and doing something about it,
> resulting in requirements of a non-obsolescent feature being described
> with the help of an obsolescent feature.

Sounds about right.

It's the same in the last public C23 draft, N3096, dated April 1, 2023.
https://www.open-std.org/jtc1/sc22/wg14/www/docs/n3096.pdf

>> 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.
>
> How about:
>
> __DATEF("%Y-%M-%d")

You'd need some special-case rules; it wouldn't quite act like a normal
macro. I presume the argument would have to be a string literal (or
something that expands to a string literal, or two or more string
literals like `__DATEF("%Y-%M" "%d")`). The form implies that something
like `__DATEF("%Y")` should also work; I'm not convinced that level of
flexibility is necessary.

> Let's nuke trailing underscores Two leading underscores give us the
> needed namespace privacy. Or just _DATEF, for that matter.

I see what you mean, but all the other mandatory macros are of the form
__FOO__. I don't think it would be good for _DATEF to stand out from
the others.

>> Question: If this is done, should __DATE__ be deprecated?
>
> Deprecating safe features used in countless code bases doesn't seem very
> productive; it's just disruptive.

I agree. The same argument could be made about deprecating asctime(),
but I don't think it's used as widely.

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