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/
