Is TeX Y2K-compliant?

Erik Frambach

January 1999

Abstract

Will TeX and related programs continue to work properly after the year 2000? This article describes how TeX deals with dates and how this affects its behavior after the year 2000.

Keywords: millennium, Y2K

What's the problem?

Many programs that have been running perfectly well for a long time could crash or otherwise cause problems at the turn of the century. The reason is that these programs internally represent years in only two digits. This means that, e.g., the year 1999 is represented as `99' and the year 2000 is represented as `00'.

Any program that attempts to do arithmetics with these truncated values will fail. My age, e.g., could be determined by subtracting my year of birth from the current year. In 1999 that would be `99' minus `60' equals `39'. But in the year 2000 it would be `00' minus `60' equals `-60'. Depending on the kind of application that makes such errors, the consequences could be devastating.

If a program behaves decently, using `large' numbers such as `1999' for internal representations, it is called Y2K-compliant (Y2K means `Year 2 Thousand'). Many companies are currently testing all their mission-critical software and hardware for Y2K-compliancy. Naturally TeX is also put to the test.

The testing procedure

There are several ways to test if a program is Y2K-compliant. The best way to test software is to scan the source code carefully for any potentially dangerous statements. Secondly, practical tests can be done to verify if a program really behaves correctly when the year turns.

In the case of TeX both tests are needed. The sources of TeX have been publically available for about 20 years and they are exceptionally well documented. This makes it easy to find any potentially dangerous program statements. However, the proof of the pudding is in the eating, so let's set up some tests to see how TeX behaves before, `during' and after the turn of the century.

Reviewing the sources

TeX's sources are set up as so-called WEB files: ASCII files that contain both the source code and the documentation. The source code can be extracted from the WEB file by a program called Tangle. This general code can be used on any operating system. A `change file' is provided for operating system specific details, such as a call to obtain the current date. These sources can be compiled into an executable.

In the file TEX.WEB (version 3.14159) we can find the following lines that contain source code dealing with the year value:

4922:  @d year_code=23 {current year of our Lord}
4985:  @d year==int_par(year_code)
5049:  year_code:print_esc("year");
5137:  primitive("year",assign_int,int_base+year_code);@/
5138:  @!@:year_}{\.{\\year} primitive@>
10329: print_char(" "); print_int(year); print_char(" ");
12262: print(" TeX output "); print_int(year); print_char(".");
24125: print_int(year mod 100); print_char(".");

The TeX primitive command \year is defined as a 4-byte signed integer with a range of -2147483648 to +2147483647, which should be quite sufficient. The modulo function applied in line 24125 turns out not to be harmful. It is only used to write non-vital information about the preloaded format to the log file. When running the emTeX 4b implementation a typical log file will show, e.g.:

(preloaded format=texput 97.9.3)

The (newer) Web2c 7.2 implementation avoids any possible confusion by supplying the full year:

(format=tex 1998.3.26)

Assuming that the operating system parses the correct year value to the compiler, any integer operation that involves the year value should work correctly.

Practical experiments

In order to prove that TeX outputs the year value correctly we can set up a few tests. The program below uses TeX's variable \year to display the current year and a little more information. This program can be run on a computer on which you change the year a number of times. This way you can determine how the program would behave in, e.g. 1990, 1998, 1999, 2000, 2001 and 3000. In any case it should return the same year value as the operating system of the computer dictates.

\newcount\YtwoK
\YtwoK = 2000
\advance \YtwoK by -\year
\def\countdown
  {It's \the\year:   % display current year
   \ifnum \YtwoK > 0 % before 2000:
     \ifcase \YtwoK  % 1999
       Time to panic!
     \or             % 1998
       Relax, still so much time.
     \or             % 1997
       Millennium?
     \else           % before 1997
       Don't worry, be happy.
     \fi
   \else             % 2000 or later:
     \ifcase -\YtwoK % 2000
       You've survived!
     \or             % 2001
       Business as usual.
     \else           % after 2001
       When's the next deadline?
     \fi
   \fi}
\countdown

Next we can run a program just before midnight 1999 to see what happens if the year turns during the run of a TeX program. The program below will display the current time (in minutes since last midnight), day, month and year in an endless loop.

\loop \message{It's now
               \the\time,
               \the\day,
               \the\month,
               \the\year}
\iftrue \repeat

From the sources it could be determined that TeX polls the operating system only once to find the current time and date. In a programmer's words: these are not functions but variables that are initialized at the start of the program. Therefore, the test program should write the same line over and over.

We have run these tests on the following implementations of TeX 3.14159:

• emTeX 386 [4b] (MS-DOS, OS/2)
• Web2c 6.1 (Unix)
• Web2c 7.0 (Unix)
• Web2c 7.2 (Windows 95/98/NT)
• Web2c 7.2 (Unix)
• Visual TeX 6.23 (Windows 95/98/NT)
• MiKTeX 1.11 (Windows 95/98/NT)
• OzTeX 3.1.1 (Apple Power Mac)

The test results were identical in all cases.

Related programs

A typical TeX implementation contains many other programs that perform specific tasks. Almost all of them do not perform any task that could induce errors because of an erroneous date value. In fact, dates are hardly used at all in these programs. Nevertheless, a few remarks about these programs are listed below.

Metafont

This program supports a date primitive, much like TeX. However, the implementation is slightly different. In mf.web we can read that the date value is represented as a 2-byte signed integer. This means that its value can range from -32768 to +32767, which is still quite sufficient.

MetaPost

This program is identical to Metafont with respect to date values.

BibTeX

This program may be involved in sorting by date. Internally BibTeX stores dates as integers with a more than sufficient range. If a BibTeX user writes a date as, say `98' instead of `1998' then sorting problems may occur. However, it's extremely unusual to refer to an article's year in two digits. In any case, this would a user's problem, not a program's problem.

MakeIndex

This program does not use dates at all, so it's unlikely to cause problems.

DVI drivers

In general DVI drivers only use dates in output to the console or to a log file, if at all. This should be completely harmless.

Statements

Naturally the Y2K issue has been discussed at the tex-implementors discussion list.

Several TeX implementors have made official Y2K statements about their products. On the Internet these statements are usually easy to find.

Some TeX implementations for which I couldn't find a statement on the Internet I contacted by email. Their responses are also listed below.

tex-implementors discussion list

From: Barbara Beeton
Subject: message for prof. knuth

don,
after a lengthy discussion on the tex-implementors discussion list, it seems advisable for me to write and ask you to consider another change to tex and metafont.

due to the way bureaucracies work, a number of people in the tex community have been asked to sign pieces of paper stating that tex is Y2K compliant.

one of them, chris rowley, had the temerity to point out that there is one place where tex now prints out a year in two-digit format and that perhaps changing this would be very simple and would save a lot of people the time otherwise needed to explain this phenomenon in the current climate of anxiety about such matters.

the code in question is

    print_int(year mod 100)

it is used only in a message giving the date of a format file. chris [Rowley, EF] has further pointed out that in the years 2000-2009, only a single digit will be printed out, a result that may not be clearly recognizable as a year.

the most compelling technical discussion of the details has (as usual) been given by peter breitenlohner:

So much has been said to this subject, that I can't resist...

1. The only place where print_int(year mod 100) is used in tex.web (and something very similar and functionally completely equivalent in metafont and metapost) is when producing the ``format_ident'' string. This string is created by initex and written to the .fmt files and displayed (to the terminal and/or transscript file aka logfile). When tex loads a format that string is retrieved from the .fmt file and displayed again. The only purpose of this ``format_ident'' string is to somehow identify the format, not nearly in a unique fashion because all formats created on the same day will have the same format_ident string. Knuth has chosen to use (year mod 100) as part of that string - probably for human readability - but some sort of hash code would serve the same purpose and might provide a unique identification.

No one in his clear mind - except possibly a burocrat - should take this use of (year mod 100) as an indication of lacking Y2K compliance!! It would, however, be nicer to use the full year. PT has, however, argued that this is not allowed, since only Don Knuth is allowed to make such changes. I think this point is not quite clear, although it would certainly be best if Knuth either makes or at least approves such a change. (emphasis added by Barbara Beeton) Otherwise such a modification must certainly live in all the system dependent change files.

Let me quote from tripman.tex:

If somebody claims to have a correct implementation of TeX, I will not believe it until I see that \.{TRIP.TEX} is translated properly. I propose, in fact, that a program must meet two criteria before it can justifiably be called TeX: (1) The person who wrote it must be happy with the way it works at his or her installation; and (2) the program must produce the correct results from \.{TRIP.TEX}.

...

\item{5.} Compare the \.{TRIP.LOG} file from step 4 with the ``master'' \.{TRIP.LOG} file of step 0. (Let's hope you put that master file in a safe place so that it wouldn't be clobbered.) There should be perfect agreement between these files except in the following respects:

\itemitem{a)} The dates and possibly the file names will naturally be different.

The last sentence could be interpreted in the sense that a four digit year in the format_ident string is legitimate.

2. It has been said that grepping {tex,mf,mp}.tex for ``year'' is not enough. This is, in principle, certainly correct. Since I know, however, these files fairly well, let me assure you that grepping is good enough in this particular case.

3. tex.web initializes date (\year, \month, and \day) and \time to the 4th July 1776, 12.00 noon. Since tex.web is Pascal based and std. Pascal does not provide such services this is certainly one way to do it. It is then left to the respective implementation (via the system dependent change file) to retrieve the correct date from the operating system and initialize \year, etc. accordingly. \year is supposed to be initialized to the current year, e.g., 1998, no truncation!!!

But: \year et al. are just some of TeX's integer parameters initialized such that they reflect the current date and time. They are otherwise completely under the user's control. Using the sequence ``\year=1940 \dump'' today yields ``40.10.20'' as part of format_ident, ``\year=2000 \dump'' yields ``0.10.10'', and ``\year=-143 \dump'' yields either ``-43.10.20'' or ``57.10.20'' - depending on how the modulo operation works for negative values (this is not specified in the Pascal Standard).

with best regards, Peter Breitenlohner

if a change to remove this pseudo-problem is delayed until 2002, then tex is liable to have to be subjected to a lot of unnecessary scrutiny, taking attention away from things that really *are* problems, and even potentially causing some sites to ban its use. i don't think that is desirable - even less desirable than my writing to you at this date about the problem.

i hope you agree.

Subject: note from Don Knuth

Dear Barbara,

Thanks for your note. It spurred me to make update my macro files for errata in TAOCP; now they are Y2K compliant!

Peter Breitenlohner's comments are 100% correct. Also, I might note that the Metafont documentation already mentions that Metafont (as it stands) cannot be run after the year 32767; the latter ``problem'' is not applicable however to TeX.

I agree that it would now be best to remove the ``mod 100'' from TeX module 1328 and from MF module 1200 (and from MetaPost in the corresponding place). I hereby give permission to implementors to make such changes in their change files. No change to the version numbers are needed.

I've actually made the changes in my personal copies of tex.web and mf.web and tex82.bug and mf85.bug and errata.eight and errata.tex; but those sources won't be updated at labrea until 2002.

I'm not changing page 23 of The TeX book - where the example was probably my original motivation for cutting to two digits, since the example wouldn't fit on a single line otherwise - nor the corresponding page of The Metafontbook. The format-identifier details are not an essential part of TeX's actions.

Incidentally, I'm not considering this to be the ``final bug'' in TeX. But it may well turn out to be the final change ever made.

Cordially, Don

On the tex-implementors discussion list Nelson Beebe raised the issue of macro packages that may use truncated year values:

Since \year is accessible to TeX packages, date truncation could also appear elsewhere in TeX distributions. I therefore checked all of the files in the TeX Live 3 tex/tex/latex tree for references to \year, and turned up just one another year truncation, in:

tex/latex/dinbrief/dinbrief.cls

In this L^ATeX class file the macro \ntoday displays the current date as ``day.month.year'' in which the year is represented as two digits. Since no calculations are applied on this value, it should be harmless.

PCTeX

Their official statement can be found on www.pctex.com/techsupp/itechinf.htm and this is what it says:

``Is PCTeX Year 2000 Compatible?

Because PCTeX and accompanying macros, etc. are operating system/date dependant; as long as you have taken proper precautions to ensure your operating system is year 2000 compliant, you will experience no change in operation, come January 1, 2000. If you need a verification letter for your files, click HERE''

The word HERE above links to ftp://ftp.crl.com/users/rw/98765/yr2000.dvi which reads:

``June 16, 1998

Year 2000 Manager

To Whom it May Concern,

The vendor warrants that each item of hardware, software, and/or firmware delivered, developed or modified under this contract shall be able to accurately process date data (including, but not limited to calculating, comparing and sequencing) from, into, and between the twentieth and twenty-first centuries, including leap year calculations, when used in accordance with the item documentation provided by the contractor, provided that all items (e.g. hardware, software, firmware) used in combination with other designated items properly exchange date data with it. The duration of this warranty and the remedies available to the customer for breach of this warranty shall be as defined in, and subject to, the terms and limitation of any general warranty provision(s) of this contract, provided that notwithstanding any provision to the contrary in such warranty provision(s), or in the absence of any such warranty provision(s), the remedies available to the customer under this warranty shall include repair or replacement of any item whose non-compliance is discovered and made known to the contractor in writing within ninety (90) days after acceptance. Nothing in the warranty shall be construed to limit any rights or remedies the customer may otherwise have under this contract with respect to defects other than Year 2000 performance.

Sincerely,

Lance Carnes President''

TrueTeX

Their statement can be found on www.truetex.com/y2k.htm and it reads:

``TeX Year 2000 (Y2K) Issues in Summary

This page summarizes the year 2000 issues surrounding TeX and METAFONT, based on discussions in the newsgroup comp.text.tex and among the members of the mailing list tex-implementors@ams.org. We attempt herein to merely set forth the chief matters at hand, without engaging the controversial aspects of what solutions should be taken.

Crashing: The programs TeX and METAFONT themselves will not crash due to dates. (However, each executable implementation depends on a run-time library and an operating system, which should be evaluated in this regard.)

Timestamps: A 2-digit year is (a) printed in logfiles, and (b) stored in format file and base file time stamps. These items should not be of general concern, because they are intended for human readers and not as input to other programs.

On November 24, 1998, Donald Knuth granted an unusual permission to modify TeX and METAFONT to use 4-digit timestamps (nearly all implementations, such as web2c, had already been doing so), saying:

I agree that it would now be best to remove the ``mod 100'' from TeX module 1328 and from MF module 1200 (and from METAPOST in the corresponding place). I hereby give permission to implementors to make such changes in their change files. No change to the version numbers are needed. [As reported by Barbara Beeton on the tex-implementors e-mail list.]

This permission means that 4-digit timestamps, while changing the output of TeX and METAFONT slightly from the current autographs, still meet Knuth's authoritative standards required of software calling itself TeX or METAFONT.

The \year primitive: TeX TRIP certification, in the strictest sense, does not require that \year return a meaningful value (TeX may be certifiably implemented on platforms that do not even supply date reporting, such as standard Pascal). The TeX book does define \year as ``the current year of our Lord'', which is the only correct meaning of \year for those implementations which can supply a meaningful value, which is to say nearly all of them.

In short, TeX implementations should provide a value in \year giving the 4-digit year Anno Domini, or the value 1776 if the platform does not support a date function. TeX does not provide any state variables to indicate whether \year contains a meaningful value, and while 1776 could have been considered a signal value for a lack of meaning to \year, this is not a standardized requirement.

External software: The TeX corpus embodies many accessory programs, such as macro packages and DVI translators, which may compute dates from the value of \year (or rarely, from timestamps). Such accessories should be checked individually for correct behavior when \year is assumed to return a correct 4-digit \year value before and after 2000. Accessories with an additional ``defensive level'' of correctness will behave reasonably when \year contains a two-digit value or a meaningless value such as 1776.''

Y&Y

Their statement can be found on www.YandY.com/Y2K.htm which reads:

``Year 2000 (Y2K)

Relative to the Year 2000, there are no date issues with Y&Y TeX System release 2.1

Y&Y TeX uses only standard calls to the Microsoft C++ library and WIN32 API to manage the dates and times for files. The operating system sets the date and time arithmetic values based on what the PC's realtime clock provides. It is the operating system, the underlying BIOS, and the realtime clock upon which Y&Y software depends for Year 2000 compliance (*)

We do not embed or implement any algorithm of our own or any third party's to compute dates in any of our products.

TeX itself does not do any computation based on dates. It simply provides informational access to the dates and times obtained from the underlying operating system. The year is not truncated to two digits when offered to the user from inside TeX source code via \year, or in information output on screen or in the log file. This information is provided ``AS IS'' without warranty of any kind, either express or implied. Any further question may be addressed to the attention of support@YandY.com

(*) Some C libraries on Unix, DOS, Windows and Macintosh will have an overflow problem in the year 2038 or 2040. Unlike some other TeX systems, some browsers, and some email programs, the Y&Y TeX System release 2.1 will not crash when run on a machine with the year set to these values.''

In an email Bertold Horn, representing Y&Y, wrote to me:

``We some time ago switched to 4 digit years in the comment string in the format file. Which is the only place where there is anything even remotely related in TeX itself. We did not feel any need for wait for Knuth to make a statement on this. In fact we have made numerous such small changes to improve TeX.

... IMHO, the Y2K problem is vastly overrated. The year 2038 and 2040 bugs are more serious. Unfortunately I won't be around to have to worry about that.

Regards, Berthold Horn.''

Visual TeX

Through email MicroPress Inc. stated:

``No statement, besides ``VTeX is fully Y2K compliant''

A statement of Y2K compliance will appear on the Web site in the near future. (With all the new things, the site has fallen behind a bit.)''

Unfortunately the full statement is still not available.

BlueSky

BlueSky's official statement can be found on www.bluesky.com/y2knote.html and it reads:

``Year 2000 Compliance

As you may or may not know, the Macintosh in general has been Y2K compliant since it was first introduced in 1984. Contrast this with Microsoft's Windows software-even the Windows 95 version is not Y2K compliant, nor is their Windows NT 4.0! See Apple's year 2000 page on the web.

Likewise, most Macintosh software is built to handle the year 2000, and Textures is no exception. Don Knuth, the author of the TeX typesetting system and the multi-volume set ``The Art of Computer Programming'' was well ahead of the curve, and TeX has been Y2K compliant since the 70's!

In short: Yes, Textures is Y2K compliant.

Apple Macintosh: the choice for the year 2000 and beyond ;-)''

emTeX

In an email Eberhard Mattes wrote the following about the millennium problem:

``AFAIK, the only problem is TeX printing only two digits of the year in the .log file. (Blame DEK.) Completely harmless.''

Conclusions

Studying the TeX sources shows that a Y2K-problem is very unlikely to appear. The practical tests revealed no problems either. TeX jobs that do calculations on dates should not be run around midnight because TeX only polls for the current time and date once, at the start of the job. But that is only natural for a program that's not supposed to run continuously: this limitation has no relation to Y2K-compliance.

TeX is a programming language that can be used to program just about anything, including applications that are clearly not Y2K-compliant. TeX itself does not do any calculations that involve date values. The value of the variable \year is an integer (with a range more than sufficient for any year value) that is provided by the operating system on which TeX runs. Therefore, we have every confidence that, when TeX is run under a Y2K-compliant operating system, it will itself be compliant. However, being freeware, no warranty (express or implied) accompanies its sources, and TeX users are therefore advised to perform their own examination and testing.