Bug 8438
Summary: | A real Y2K problem in tmac.m | ||
---|---|---|---|
Product: | [Retired] Red Hat Linux | Reporter: | degraaf |
Component: | groff | Assignee: | Cristian Gafton <gafton> |
Status: | CLOSED ERRATA | QA Contact: | |
Severity: | medium | Docs Contact: | |
Priority: | medium | ||
Version: | 6.1 | ||
Target Milestone: | --- | ||
Target Release: | --- | ||
Hardware: | All | ||
OS: | Linux | ||
Whiteboard: | |||
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: | --- | Target Upstream Version: | |
Embargoed: |
This was fixed in the groff errata. |
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.)