The ambiguity arises from only showing the year as two digits and from different software adopting different date display formats. Had the date been 00/02/03 or 02/03/97 it would have been easy to figure out the year. But beginning in 2001 interpreting two-digit years will become more difficult. We might call this the Year 2001 Problem. It can affect both system software and application software.
As a Unisys 2200 user, I work with system software that displays dates in inconsistent formats, usually with a two-digit year. For example, the Integrated Recovery Utility (IRU) displays dates in YY/MM/DD format, whereas the File Administration System (FAS) prefers MM/DD/YY format. And I've counted at least half a dozen different date formats in OS2200's console messages.
Unisys published the Standard of 2027 for interpreting two-digit years in their 2200/CPIX software (00 to 27 means 2000 to 2027 and 28 to 99 means 1928 to 1999). Unfortunately, the Standard of 2027 does not specify where within the date the year must be placed. Thus, some software places the year at the first of the date and other software places it at the end. The user is expected to memorize the location for each product, figure it out in context, or guess. It's clear that the Unisys Standard of 2027 was designed to minimze the amount of work required to bring Unisys software into 'compliance', rather than for the convenience of the users of that software.
Of course, it's not just Unisys software or even system software in general that's prone to ambiguous date displays. Application software may also suffer the problem.
Some will argue that the reader can figure out the year in context. This is often true. Events shown on a system console are very recent. A utility bill that arrives in the mail is not likely to be from two years ago. But many kinds of dates can be older. These include tape and file creation dates, asset purchase dates, employee hire dates, etc. And even if the reader is able to figure out the year in context, she shouldn't need to. Software should display dates in a simple, unambiguous format so that the user need not play detective.
I make two suggestions for those who design software. First, choose a standard external date display format and follow it consistently. (An external date format is that displayed to human readers, whereas an internal date format is that stored in a file.) The chosen format should be easily understood by its users. Sometimes the constraints of 80-column screens and 132- column pages force brevity, but the preferred format should include a four-digit year.
Unfortunately, different countries use different external date formats and sometimes an individual company will use its own unique format. Americans favor month/day/year, although this format is not popular in the rest of the world. Much of the former British Empire prefers day/month/year. Many other countries put the year first and use other separator characters such as minus sign, period or space. My favorite is YYYY-MM-DD, which is part of ISO 8601, the International Standards Organization's standard date and time formats.
Second, if you distribute your software widely, you should allow your users to customize external date format to suit local preference. I've long thought that operating systems should provide a date configuration parameter that the customer could set. A system service routine could translate common internal date formats (including DATE$, TDATE$, and DWTIME$ on OS2200) to the desired external format. System and application software would simply pass an internal date to the service routine, which would determine the site-standard (or user-preferred) external format and return the date in that format.
Unisys recognizes the value of internationalization and localization of software. For an excellent discussion in a 2200 context, see OS2200 Internationalization Planning and Implementation Guide (7833 4588-001). The Extended Language Message System provides some of the needed functionality. But, so far, I've not seen any 2200 system software--including offerings from Unisys--that allows customization of date display format. I can't even name a product that displays all dates in a consistent format using a four-digit year.
Currently the year 2000 is uppermost in everyone's mind. It's a matter of life and death for software. The year 2001 problem is less critical. It's more a matter of adequate software versus excellent software, and of disciplined interfaces versus ad hoc interfaces. But since we're changing so much date-related code for 2000, isn't this the time to standardize date display formats?