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

Groups > comp.std.c > #6555

Re: C23: asctime is obsolescent

Show all headers | View raw

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/

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