From Newsgroup: comp.std.c

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?
--
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 */
--- Synchronet 3.19c-Linux NewsLink 1.113

From Newsgroup: comp.std.c

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().
--- Synchronet 3.20a-Linux NewsLink 1.113

From Newsgroup: comp.std.c

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?

Also it seems ill advised to designate asctime() as either
obsolescent or deprecated.
--- Synchronet 3.20a-Linux NewsLink 1.113

From Newsgroup: comp.std.c

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.

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)

Similar comments apply to __TIME__, which also refers to asctime().

--- Synchronet 3.20a-Linux NewsLink 1.113

From Newsgroup: comp.std.c

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.

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.
--
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 */
--- Synchronet 3.20a-Linux NewsLink 1.113

From Newsgroup: comp.std.c

On 03/01/2023 01:47, Keith Thompson wrote:

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.

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.

IMHO, introducing __ISODATE__ and then deprecating __DATE__ would be the
right move.

Note that deprecating __DATE__ does not mean removing it from the
standard, and certainly not from C compilers. It simply means that __ISODATE__ is the preferred way to put a "compile date" into the code,
while __DATE__ is kept for backwards compatibility. And I think most
people will agree that __ISODATE__ gives a more useful, parseable,
flexible and international format than the very USA-centric,
English-centric, mixed-endian and mixed numeric/text format of __DATE__.

As for deprecating asctime(), I'd vote for that. It is such a very
specific and very ugly format - AFAIK it is not common even in the USA
to put the time in the middle of date. And as described in the
standard, it is nothing that you can't do with a simple sprintf() call.


Another option for build timestamps would be to introduce a macro "__BUILD_TM__" which would generate data suitable for :

const struct tm build_tm = __BUILD_TM__;

Then people could get the build time and date in a manner suitable for printing version information in whatever format suits their needs.


(Personally, I do not use any of these in my code - it is important to
me that my builds are reproducible. While build timestamps would be
nice, reproducibility overrides that for me.)



--- Synchronet 3.20a-Linux NewsLink 1.113

From Newsgroup: comp.std.c

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
--- Synchronet 3.20a-Linux NewsLink 1.113

From Newsgroup: comp.std.c

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 */
--- Synchronet 3.20a-Linux NewsLink 1.113

From Newsgroup: comp.std.c

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/
--- Synchronet 3.20a-Linux NewsLink 1.113

From Newsgroup: comp.std.c

On 1/4/23 11:22, Phil Carmody wrote:

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.

I'm not sure what you mean by that. If what you mean is applicable in
this context, it seems clearly false. The asc in asctime stands for
ASCII, and the A in ASCII stands for American, and because of that it's entirely reasonable for asctime() to return a pointer to a date
formatted in a style specific to the US. Given that C is now an
international standard, for precisely that reason, it's inappropriate
for asctime() to be part of the C standard library, except for backwards compatibility reasons.
Given that I personally have found it pretty much useless (mainly
because of the terminating newline, but also partly because of the inappropriate date format - I am a US citizen, but prefer ISO 8601
because it sorts properly), I won't be annoyed if they first deprecate
it and then remove it.

--- Synchronet 3.20a-Linux NewsLink 1.113

From Newsgroup: comp.std.c

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.
--- Synchronet 3.20a-Linux NewsLink 1.113

From Newsgroup: comp.std.c

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.
--- Synchronet 3.20a-Linux NewsLink 1.113

From Newsgroup: comp.std.c

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.

Do you have a suggestion for a better name?
--
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 */
--- Synchronet 3.20a-Linux NewsLink 1.113

From Newsgroup: comp.std.c

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.

Do you have a suggestion for a better name?

The macro name will be rather long if it is to capture all the
semantics. ISO 8601 or 9899, basic or extended, calendar date or week
date, etc. It is better to treat it as a name that is not confusing and
can be looked up in the standard to confirm its exact form.

How about __YYYY_MM_DD__ if extended format or __YYYYMMDD__ if basic? I
am not advocating adding both, just that the name should match the
choice made.
--
Pete Forman
--- Synchronet 3.20a-Linux NewsLink 1.113

From Newsgroup: comp.std.c

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.

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

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.
--- Synchronet 3.20a-Linux NewsLink 1.114

From Newsgroup: comp.std.c

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
--- Synchronet 3.20a-Linux NewsLink 1.114

From Newsgroup: comp.std.c

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 */
--- Synchronet 3.20a-Linux NewsLink 1.114

From Newsgroup: comp.std.c

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 */
--- Synchronet 3.20a-Linux NewsLink 1.114

From Newsgroup: comp.std.c

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.

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.

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.
--- Synchronet 3.20a-Linux NewsLink 1.114

From Newsgroup: comp.std.c

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 */
--- Synchronet 3.20a-Linux NewsLink 1.114

From Newsgroup: comp.std.c

On 2023-08-14 01:47, Keith Thompson wrote:

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

Why __YYYMMDD__ (3 Ys, 2 Ms, 2 Ds). Why not simply __YMD__, which I
don't think is taken and is even shorter than __DATE__ .

For additional stability, add a rule in the standard that all 3
date/time macros must refer to the exact same point in time, which must
be within the system time tolerance of preprocessing the program source
code, possibly even during. For example, if the system only tracks the
time in centi-hours (36 seconds each) and preprocessing a particular C
program takes 0.1s starting at 2023-08-17T23:59:59, the timestamp
used for the macros may be 2023-08-17T23:59:24 or 2023-08-18T00:00:00 .

That additional rule above has been carefully written to allow all the following 3 implementations:

OK1. When starting the preprocessor, detect the current date and time
in a way that doesn't suffer from race conditions, then use that
value throughout.

OK2. When first expanding either of the 3 macros, capture the
date/time value to be used, thus avoiding the I/O cost of doing so
when the program doesn't use the value.

OK3. When initiating the preprocessing of the program, the user or
build script specifies an exact date/time to be used by any
available means, such as command line arguments, environment
variables, a control file etc. This implementation is particularly
useful when trying to produce identical programs at different times
and places (so called reproducible builds).

But it doesn't allow the following bad implementations:

BAD1. Expand all 3 macros to the timestamp of the source file. This
would be inconsistent with past implementation practice.

BAD2. Capture the date or time every time either macro is expanded.
This causes a race condition if time crosses midnight during
preprocessing (The example above might end up returning
__YMD__ __TIME__ as "2023-08-17" "00:00:00"

Enjoy

Jakob
--
Jakob Bohm, CIO, Partner, WiseMo A/S. https://www.wisemo.com
Transformervej 29, 2860 Søborg, Denmark. Direct +45 31 13 16 10
This public discussion message is non-binding and may contain errors.
WiseMo - Remote Service Management for PCs, Phones and Embedded
--- Synchronet 3.20a-Linux NewsLink 1.114

From Newsgroup: comp.std.c

Jakob Bohm <jb-usenet@wisemo.com.invalid> writes:

On 2023-08-14 01:47, Keith Thompson wrote:

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

Why __YYYMMDD__ (3 Ys, 2 Ms, 2 Ds).

Just a typo. I meant __YYYYMMDD__.

Why not simply __YMD__, which I
don't think is taken and is even shorter than __DATE__ .

Yes, I mentioned __YMD__ in a previous post.

For additional stability, add a rule in the standard that all 3
date/time macros must refer to the exact same point in time, which must
be within the system time tolerance of preprocessing the program source
code, possibly even during. For example, if the system only tracks
the time in centi-hours (36 seconds each) and preprocessing a
particular C
program takes 0.1s starting at 2023-08-17T23:59:59, the timestamp
used for the macros may be 2023-08-17T23:59:24 or 2023-08-18T00:00:00 .

That additional rule above has been carefully written to allow all the following 3 implementations:

OK1. When starting the preprocessor, detect the current date and time
in a way that doesn't suffer from race conditions, then use that
value throughout.

OK2. When first expanding either of the 3 macros, capture the
date/time value to be used, thus avoiding the I/O cost of doing so
when the program doesn't use the value.

OK3. When initiating the preprocessing of the program, the user or
build script specifies an exact date/time to be used by any
available means, such as command line arguments, environment
variables, a control file etc. This implementation is particularly
useful when trying to produce identical programs at different times
and places (so called reproducible builds).

But it doesn't allow the following bad implementations:

BAD1. Expand all 3 macros to the timestamp of the source file. This
would be inconsistent with past implementation practice.

BAD2. Capture the date or time every time either macro is expanded.
This causes a race condition if time crosses midnight during
preprocessing (The example above might end up returning
__YMD__ __TIME__ as "2023-08-17" "00:00:00"

Frankly, I don't think all that is necessary.

The standard currently says:

__DATE__ The date of translation of the preprocessing translation unit:
a character string literal of the form "Mmm dd yyyy", where the
names of the months are the same as those generated by the
asctime function, and the first character of dd is a space
character if the value is less than 10. If the date of
translation is not available, an implementation-defined valid
date shall be supplied.
...
__TIME__ The time of translation of the preprocessing translation unit:
a character string literal of the form "hh:mm:ss" as in the
time generated by the asctime function. If the time of

I think the phrase "translation of the preprocessing translation unit"
excludes an implementation that expands to a date or time when the line
is reached, which avoids your BAD2 error crossing midnight.

Allowing the user to specify a time other than the current one would
arguably be non-conforming, though a lot of options are non-conforming.
And both gcc and clang already allow -D__DATE__=...

I don't think the part about the time being within the system time
tolerance is necessary. An implementation would have to go out of its
way not to do that anyway.
--
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 */
--- Synchronet 3.20a-Linux NewsLink 1.114

From Newsgroup: comp.std.c

On 2023-08-17 22:14, Keith Thompson wrote:

Jakob Bohm <jb-usenet@wisemo.com.invalid> writes:

On 2023-08-14 01:47, Keith Thompson wrote:

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

Why __YYYMMDD__ (3 Ys, 2 Ms, 2 Ds).

Just a typo. I meant __YYYYMMDD__.

Why not simply __YMD__, which I
don't think is taken and is even shorter than __DATE__ .

Yes, I mentioned __YMD__ in a previous post.

For additional stability, add a rule in the standard that all 3
date/time macros must refer to the exact same point in time, which must
be within the system time tolerance of preprocessing the program source
code, possibly even during. For example, if the system only tracks
the time in centi-hours (36 seconds each) and preprocessing a
particular C
program takes 0.1s starting at 2023-08-17T23:59:59, the timestamp
used for the macros may be 2023-08-17T23:59:24 or 2023-08-18T00:00:00 .

That additional rule above has been carefully written to allow all the
following 3 implementations:

OK1. When starting the preprocessor, detect the current date and time
in a way that doesn't suffer from race conditions, then use that
value throughout.

OK2. When first expanding either of the 3 macros, capture the
date/time value to be used, thus avoiding the I/O cost of doing so
when the program doesn't use the value.

OK3. When initiating the preprocessing of the program, the user or
build script specifies an exact date/time to be used by any
available means, such as command line arguments, environment
variables, a control file etc. This implementation is particularly
useful when trying to produce identical programs at different times
and places (so called reproducible builds).

But it doesn't allow the following bad implementations:

BAD1. Expand all 3 macros to the timestamp of the source file. This
would be inconsistent with past implementation practice.

BAD2. Capture the date or time every time either macro is expanded.
This causes a race condition if time crosses midnight during
preprocessing (The example above might end up returning
__YMD__ __TIME__ as "2023-08-17" "00:00:00"

Frankly, I don't think all that is necessary.

The standard currently says:

__DATE__ The date of translation of the preprocessing translation unit:
a character string literal of the form "Mmm dd yyyy", where the
names of the months are the same as those generated by the
asctime function, and the first character of dd is a space
character if the value is less than 10. If the date of
translation is not available, an implementation-defined valid
date shall be supplied.
...
__TIME__ The time of translation of the preprocessing translation unit:
a character string literal of the form "hh:mm:ss" as in the
time generated by the asctime function. If the time of

Neither quote specifies that the values need to be consistent, nor
that a longer preprocessing time cannot cause an implementation to
provide values indicating when each occurrence is expanded.

I think the phrase "translation of the preprocessing translation unit" excludes an implementation that expands to a date or time when the line
is reached, which avoids your BAD2 error crossing midnight.

Allowing the user to specify a time other than the current one would
arguably be non-conforming, though a lot of options are non-conforming.
And both gcc and clang already allow -D__DATE__=...

I don't think the part about the time being within the system time
tolerance is necessary. An implementation would have to go out of its
way not to do that anyway.

The reference to system tolerance was intended as a relaxation to
dissuade implementations from going overboard in trying to get a
correct time, such as by artificially slowing down the preprocessor
to the clock advancement rate. Note that my OK3 implementation
wouldn't be strictly compliant, but could exist in a non-normative
note to inspire such non-normative behavior needed to ensure
compliance with security procedures that validate compilation by
independent recompilation of certified sources.



Enjoy

Jakob
--
Jakob Bohm, CIO, Partner, WiseMo A/S. https://www.wisemo.com
Transformervej 29, 2860 Søborg, Denmark. Direct +45 31 13 16 10
This public discussion message is non-binding and may contain errors.
WiseMo - Remote Service Management for PCs, Phones and Embedded
--- Synchronet 3.20a-Linux NewsLink 1.114

From Newsgroup: comp.std.c

Jakob Bohm <jb-usenet@wisemo.com.invalid> writes:

On 2023-08-17 22:14, Keith Thompson wrote:

Jakob Bohm <jb-usenet@wisemo.com.invalid> writes:

On 2023-08-14 01:47, Keith Thompson wrote:

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

Why __YYYMMDD__ (3 Ys, 2 Ms, 2 Ds).

Just a typo. I meant __YYYYMMDD__.

Why not simply __YMD__, which I
don't think is taken and is even shorter than __DATE__ .

Yes, I mentioned __YMD__ in a previous post.

For additional stability, add a rule in the standard that all 3
date/time macros must refer to the exact same point in time, which must
be within the system time tolerance of preprocessing the program source
code, possibly even during. For example, if the system only tracks
the time in centi-hours (36 seconds each) and preprocessing a
particular C
program takes 0.1s starting at 2023-08-17T23:59:59, the timestamp
used for the macros may be 2023-08-17T23:59:24 or 2023-08-18T00:00:00 .

That additional rule above has been carefully written to allow all the
following 3 implementations:

OK1. When starting the preprocessor, detect the current date and time >>> in a way that doesn't suffer from race conditions, then use that
value throughout.

OK2. When first expanding either of the 3 macros, capture the
date/time value to be used, thus avoiding the I/O cost of doing so >>> when the program doesn't use the value.

OK3. When initiating the preprocessing of the program, the user or
build script specifies an exact date/time to be used by any
available means, such as command line arguments, environment
variables, a control file etc. This implementation is particularly >>> useful when trying to produce identical programs at different times >>> and places (so called reproducible builds).

But it doesn't allow the following bad implementations:

BAD1. Expand all 3 macros to the timestamp of the source file. This
would be inconsistent with past implementation practice.

BAD2. Capture the date or time every time either macro is expanded.
This causes a race condition if time crosses midnight during
preprocessing (The example above might end up returning
__YMD__ __TIME__ as "2023-08-17" "00:00:00"

Frankly, I don't think all that is necessary.
The standard currently says:
__DATE__ The date of translation of the preprocessing translation unit:
a character string literal of the form "Mmm dd yyyy", where the
names of the months are the same as those generated by the
asctime function, and the first character of dd is a space
character if the value is less than 10. If the date of
translation is not available, an implementation-defined valid
date shall be supplied.
...
__TIME__ The time of translation of the preprocessing translation unit:
a character string literal of the form "hh:mm:ss" as in the
time generated by the asctime function. If the time of

Neither quote specifies that the values need to be consistent, nor
that a longer preprocessing time cannot cause an implementation to
provide values indicating when each occurrence is expanded.

I think the phrase "translation of the preprocessing translation unit"
excludes an implementation that expands to a date or time when the line
is reached, which avoids your BAD2 error crossing midnight.
Allowing the user to specify a time other than the current one would
arguably be non-conforming, though a lot of options are non-conforming.
And both gcc and clang already allow -D__DATE__=...
I don't think the part about the time being within the system time
tolerance is necessary. An implementation would have to go out of its
way not to do that anyway.

The reference to system tolerance was intended as a relaxation to dissuade implementations from going overboard in trying to get a
correct time, such as by artificially slowing down the preprocessor
to the clock advancement rate. Note that my OK3 implementation
wouldn't be strictly compliant, but could exist in a non-normative
note to inspire such non-normative behavior needed to ensure
compliance with security procedures that validate compilation by
independent recompilation of certified sources.

Enjoy

Jakob

A disadvantage of __YYYYMMDD__ is that it looks to me, at least, as if
it is ISO 8601 basic format (e.g. 20230821). The proposal being
discussed is using extended format.

As I said in a previous post it would be unwieldy to try to capture all
the detail. It is better to treat it as a name that is not confusing and
can be looked up in the standard to confirm its exact form.
--
Pete Forman
https://payg.pythonanywhere.com/
--- Synchronet 3.20a-Linux NewsLink 1.114

From Newsgroup: comp.std.c

Keith Thompson <Keith.S.Thompson+u@gmail.com> writes:

[...]

I thought I should respond and say I have read through your
comments, and having done so I think I understand your views
and in some cases your reasons for having them. I don't
have anything to add to my earlier comments.
--- Synchronet 3.20a-Linux NewsLink 1.114