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.

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

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.

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.

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

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

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

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/

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.