Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.std.c > #6544

Re: C23: asctime is obsolescent

Show all headers | View raw

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

Back to comp.std.c | Previous | Next — Previous in thread | Next in thread | Find similar

Thread

C23: asctime is obsolescent Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2022-11-23 18:12 -0800
  Re: C23: asctime is obsolescent Tim Rentsch <tr.17687@z991.linuxsc.com> - 2023-01-02 08:11 -0800
    Re: C23: asctime is obsolescent Richard Damon <Richard@Damon-Family.org> - 2023-01-02 12:11 -0500
      Re: C23: asctime is obsolescent Tim Rentsch <tr.17687@z991.linuxsc.com> - 2023-01-29 10:33 -0800
        Re: C23: asctime is obsolescent Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2023-01-29 16:49 -0800
          Re: C23: asctime is obsolescent Pete Forman <petef4+usenet@gmail.com> - 2023-01-30 23:23 +0000
          Re: C23: asctime is obsolescent Tim Rentsch <tr.17687@z991.linuxsc.com> - 2023-07-20 10:11 -0700
            Re: C23: asctime is obsolescent Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2023-07-20 15:04 -0700
              Re: C23: asctime is obsolescent Tim Rentsch <tr.17687@z991.linuxsc.com> - 2023-08-13 15:26 -0700
                Re: C23: asctime is obsolescent Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2023-08-13 16:47 -0700
                Re: C23: asctime is obsolescent Jakob Bohm <jb-usenet@wisemo.com.invalid> - 2023-08-17 21:18 +0200
                Re: C23: asctime is obsolescent Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2023-08-17 13:14 -0700
                Re: C23: asctime is obsolescent Jakob Bohm <jb-usenet@wisemo.com.invalid> - 2023-08-18 01:26 +0200
                Re: C23: asctime is obsolescent Pete Forman <petef4+usenet@gmail.com> - 2023-08-21 17:42 +0100
                Re: C23: asctime is obsolescent Tim Rentsch <tr.17687@z991.linuxsc.com> - 2023-08-29 02:37 -0700
    Re: C23: asctime is obsolescent Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2023-01-02 16:47 -0800
      Re: C23: asctime is obsolescent David Brown <david.brown@hesbynett.no> - 2023-01-03 09:40 +0100
      Re: C23: asctime is obsolescent Pete Forman <petef4+usenet@gmail.com> - 2023-01-03 15:15 +0000
        Re: C23: asctime is obsolescent Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2023-01-03 10:35 -0800
        Re: C23: asctime is obsolescent Phil Carmody <pc+usenet@asdf.org> - 2023-01-04 18:22 +0200
          Re: C23: asctime is obsolescent James Kuyper <jameskuyper@alumni.caltech.edu> - 2023-01-04 15:04 -0500
      Re: C23: asctime is obsolescent Tim Rentsch <tr.17687@z991.linuxsc.com> - 2023-01-29 10:43 -0800
  Re: C23: asctime is obsolescent Tim Rentsch <tr.17687@z991.linuxsc.com> - 2023-01-02 08:20 -0800
  Re: C23: asctime is obsolescent Kaz Kylheku <864-117-4973@kylheku.com> - 2023-07-20 17:29 +0000
    Re: C23: asctime is obsolescent Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2023-07-20 15:20 -0700

csiph-web