bugGNU roff - Bugs: bug #60372, remove obsolete (and somewhat...

 
 

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

Submitter:  Dave <barx>
Submitted:  Sun 11 Apr 2021 10:48:45 AM UTC
   
 
Category:  Core Severity:  2 - Minor
Item Group:  Documentation Status:  Fixed
Privacy:  Public Assigned to:  gbranden
Open/Closed:  Closed Planned Release:  1.23.0
* Mandatory Fields

Add a New Comment Rich Markup
   

Mon 12 Apr 2021 10:08:54 AM UTC, comment #3: 


commit 846d7c9fbca1ce6bb9727b4b750d395085e52c0e
Author: Dave Kemper <saint.snit@gmail.com>
Date:   Sun Apr 11 10:48:45 2021 +0000

    groff(7): Drop discussion of Y2K issues.

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


G. Branden Robinson <gbranden>
Group administrator
Mon 12 Apr 2021 02:43:22 AM UTC, comment #2: 

comment #1:

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


That's entirely appropriate; groff shouldn't attempt to reinvent anything in libc, and if a system's libc is date-limited, incorrect dates in groff will be among the less severe problems those users will experience come epoch rollover.

So I agree, there's nothing here that needs to be addressed in the groff documentation.

Dave <barx>
Group Member
Sun 11 Apr 2021 02:30:11 PM UTC, 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.

G. Branden Robinson <gbranden>
Group administrator
Sun 11 Apr 2021 10:48:45 AM UTC, original submission:  

We should no longer need to explicitly document Y2K compliance.  (If anything, we should document Y2K38 compliance, as we're closer to that year than to 2000.)

And the way man/groff.7.man currently documents it is not even accurate.  Of the yr register it says, "Current year minus 1900.  For Y2K compliance use register 'year' instead."  But register yr is fully Y2K compliant; it is merely, as documented, offset by 1900.  In 2021 it holds the correct value of 121.

Thus the attached patch removes all mentions of Y2K on this man page.  (I don't know groff's Y2K38 readiness, so I didn't add anything about that.)

Dave <barx>
Group Member

 

(Note: upload size limit is set to 16384 kB, after insertion of the required escape characters.)

Attach Files:
   
   
Comment:
   

Attached Files
file #51243:  groff.7.man.y2k.patch added by barx (379B - text/x-patch)

 

Depends on the following items: None found

Items that depend on this one: None found

 

Carbon-Copy List
  • -email is unavailable- added by gbranden (Posted a comment)
  • -email is unavailable- added by barx (Submitted the item)
  •  

    There are 0 votes so far. Votes easily highlight which items people would like to see resolved in priority, independently of the priority of the item set by tracker managers.

    Only logged-in users can vote.

     

    Follow 6 latest changes.

    Date Changed by Updated Field Previous Value => Replaced by
    2021-04-12 gbranden StatusIn Progress Fixed
        Open/ClosedOpen Closed
        Planned ReleaseNone 1.23.0
    2021-04-11 gbranden StatusNone In Progress
        Assigned toNone gbranden
    2021-04-11 barx Attached File- Added groff.7.man.y2k.patch, #51243

    Back to the top

    Powered by Savane 3.13-caa5.
    Corresponding source code