Data which is stored or exchanged and which contains century-ambiguous two-digit years, such as "05/13/29", can present Y2K problems. Different computer programs (and even humans) might variously interpret such dates as falling either in the 20th century, as May 13, 1929 or in the 21st century, as May 13, 2029. This could potentially lead to inaccurate data and faulty results.
Under most circumstances, when specifying date formats in your data files or custom scripts or programs, or when entering dates into spreadsheets, databases, and the like, you should thus use dates with unambiguous four-digit years.
You might consider adopting one of two methods for representing dates with four-digit years as a standard within your UC Berkeley campus department. (In the examples below, "mm" is used to represent the month, "dd" the day, and "yyyy" the year, including the century):
mm/dd/yyyy
yyyy-mm-dd
Unfortunately, at least a few application programs have programming flaws which do not allow them to properly handle dates in one or both of these four-digit-year formats. (We expect that a somewhat greater number of programs may have difficulties handling dates in the ISO 8601 "yyyy-mm-dd" format, as this format places the year in a different position within the date than is traditional in the USA, and also uses a different separator character.)
For this reason, we recommend that you check with the vendors, developers, or maintainers of your key application programs, and/or perform tests on your own with non-critical sample data files, before switching to a different method for representing dates.
In addition, even if your own programs can accept and manipulate dates in one or both of these four-digit year formats, some other programs with which your programs may be sharing data might not. As a result, we recommend that you also check with your data interchange partners to make sure that switching date formats won't cause any problems.