If you detect any Year 2000 limitations in your code, you should change
the code and/or the data storage if at all possible. In cases where an
external standard or convention prohibits changing 2-digit year date
formats, provide an alternative or work around the restriction and
thoroughly document the condition.
In general, code that works with and stores a 2-digit year should be
changed to use a 4-digit year. When this is not possible, you may be
able to use a century window to define how 2-digit year values are to
be interpreted; for example, OpenVMS Alpha allows the use of global
cell EXE$GL_TRANSITION_YEAR, which defines 57 to 99 to be interpreted
as 1957 to 1999, and 00 to 56 to be interpreted as 2000 to 2056.
Other data storage options include, but are not limited to, the OpenVMS
binary-format time quadword, the OpenVMS text-format time (for example,
"10-DEC-1997 11:59:52.61"), the Coordinated Universal Time (UTC)
binary-format time, and the UTC text-format time.
» Return to Guidelines for Year 2000 Code Investigations home page