Bug 8438 - A real Y2K problem in tmac.m
Summary: A real Y2K problem in tmac.m
Status: CLOSED ERRATA
Alias: None
Product: Red Hat Linux
Classification: Retired
Component: groff   
(Show other bugs)
Version: 6.1
Hardware: All
OS: Linux
medium
medium
Target Milestone: ---
Assignee: Cristian Gafton
QA Contact:
URL:
Whiteboard:
Keywords:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2000-01-13 02:46 UTC by degraaf
Modified: 2008-05-01 15:37 UTC (History)
0 users

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2000-02-05 19:48:20 UTC
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

Description degraaf 2000-01-13 02:46:15 UTC
Omigod - a Real Y2K problem!
In the MM macro package - tmac.m the default date prints as
	January 12, 19100
when the .ND macro is omitted.
Obviously this is easily circumvented by using .ND but it's just
about the only Y2K problem I've come across in all of Linux.

This seems to fix it:

# diff tmac.mSAV tmac.m
2623,2624c2623,2624
< .ie \\n[yr]<50 .ds cov*new-date \\*[MO\\n[mo]] \\n[dy], 20\\n[yr]
< .el .ds cov*new-date \\*[MO\\n[mo]] \\n[dy], 19\\n[yr]
---
> .nr cov*year 1900+\n[yr]
> .ds cov*new-date \*[MO\n[mo]] \n[dy], \n[cov*year]


Someone with more competence than me ought to check this out.

Please don't "fix" this by dropping tmac.m as is presently being done.
(see my earlier Bugzilla #8362.)

Comment 1 Bill Nottingham 2000-02-05 19:48:59 UTC
This was fixed in the groff errata.


Note You need to log in before you can comment on or make changes to this bug.