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?
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 <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().
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().
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.
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.
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
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 <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.
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.
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)
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.
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?
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?
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 <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.
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.
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 <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.
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"
...
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__".
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.
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:Just a typo. I meant __YYYYMMDD__.
...
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 IYes, I mentioned __YMD__ in a previous post.
don't think is taken and is even shorter than __DATE__ .
For additional stability, add a rule in the standard that all 3Frankly, I don't think all that is necessary.
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"
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
Sysop: | Keyop |
---|---|
Location: | Huddersfield, West Yorkshire, UK |
Users: | 335 |
Nodes: | 16 (2 / 14) |
Uptime: | 150:31:14 |
Calls: | 7,411 |
Calls today: | 1 |
Files: | 12,670 |
Messages: | 5,613,282 |