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