[bug #60372] remove obsolete (and somewhat misleading) Y2K info from groff(7)

[G. Branden Robinson]

Update of bug #60372 (project groff):

                  Status:                    None => In Progress            
             Assigned to:                    None => gbranden               

    _______________________________________________________

Follow-up Comment #1:

Thanks, Dave.

I don't think there's much if anything to say about Y2K38; as noted around the
beginning of this year in the SOURCE_DATE_EPOCH semantics discussion, groff is
wholly dependent on the underlying C library function localtime() to convert a
time_t into the civil calendar components that are meaningful to humans. 
init_registers() in input.cpp does this work; see
https://git.savannah.gnu.org/cgit/groff.git/tree/src/roff/troff/input.cpp#n8203
.

As you can see there's some flexibility with respect to the data type used to
store the number of seconds since the epoch.  The C standard allows a long
integer to be as narrow as 32 bits; any system using that type needs to
migrate to time_t to avoid Y2K38 issues.

For better or worse, we're at the mercy of the system libc to get year 2038
right.

    _______________________________________________________

Reply to this item at:

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

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