Bugzilla will be upgraded to version 5.0. The upgrade date is tentatively scheduled for 2 December 2018, pending final testing and feedback.
Bug 8438 - A real Y2K problem in tmac.m
A real Y2K problem in tmac.m
Product: Red Hat Linux
Classification: Retired
Component: groff (Show other bugs)
All Linux
medium Severity medium
: ---
: ---
Assigned To: Cristian Gafton
Depends On:
  Show dependency treegraph
Reported: 2000-01-12 21:46 EST by degraaf
Modified: 2008-05-01 11:37 EDT (History)
0 users

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

Attachments (Terms of Use)

  None (edit)
Description degraaf 2000-01-12 21:46:15 EST
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
< .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 14:48:59 EST
This was fixed in the groff errata.

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