[bug #63509] ctime(3) is obsolescent

[G. Branden Robinson]

Update of bug #63509 (project groff):

              Item Group:                    None => Lint                   
                  Status:                    None => Postponed              

    _______________________________________________________

Follow-up Comment #1:


[comment #0 original submission:]
> Subject: ctime(3) is obsolescent
> 
> See ctime(3) (POSIX.1-2008) and
> www.open-std.org/JTC1/SC22/WG14/www/docs/n3047.pdf.

Okay.  That doesn't change the fact that it's familiar to a lot of C
programmers, which is the point (in the documentation).
 
>   Used in 
> 
> devices/grohtml/grohtml.1.man:.MR ctime 3
> devices/grohtml/post-html.cpp:          .put_string(ctime(&t),
strlen(ctime(&t))-1)
> devices/grohtml/post-html.cpp:      .put_string(ctime(&t),
strlen(ctime(&t))-1)
> devices/grops/grops.1.man:.MR ctime 3
> devices/grops/ps.cpp:    fputs(ctime(&t), out.get_file());
> roff/groff/groff.1.man:.MR ctime 3
> roff/troff/troff.1.man:.MR ctime 3

The man page references and HTML output driver code can likely switch to
`localtime()`.
 
>   The mentioning of "ctime(3)" in man pages ("SOURCE_DATE_EPOCH") is
> irrelevant (implementation detail which can change and thus cause lost
> time by updating that).

Yes, it's an implementation detail that may change; the key fact to
communicate is that groff doesn't compute the wall clock time for itself, but
relies upon the operating environment.

And I reject entirely any suggestion that "SOURCE_DATE_EPOCH" (and "TZ") are
irrelevant.  Perhaps you missed the discussion and/or the NEWS item about
their importance.


o The semantics of the environment variable SOURCE_DATE_EPOCH (support
  for which was added in 1.22.4) to groff were not established with
  respect to time zone selection, prompting divergent interpretations;
  Debian and distributions derived from it have for several years
  patched groff to implicitly use UTC as the time zone when interpreting
  the current time (or SOURCE_DATE_EPOCH) as a local time.  While a
  convenient and defensible choice for reproducible build efforts, it
  runs against the grain of user expectations.  Systems programmers like
  time zone-invariant, monotonically increasing clocks; the broader
  user base usually prefers a clock that follows an applicable civil
  calendar.  groff programs now reckon SOURCE_DATE_EPOCH with respect to
  the local time zone.  Users of SOURCE_DATE_EPOCH may wish to also set
  the TZ environment variable.




    _______________________________________________________

Reply to this item at:

  <https://savannah.gnu.org/bugs/?63509>

_______________________________________________
Message sent via Savannah
https://savannah.gnu.org/