Microsoft Year 2000 Readiness Disclosure & Resource Center

Preparing Office Solutions for the Year 2000

This section identifies issues that are specific to each of the products that have not already been covered in this paper.

Microsoft Access

1. Using the Short Date Input Mask on form controls prevents data-entry of four digit years, regardless of the Windows Control Panel Short Date setting. Additionally, custom InputMask settings may preclude the entry of four digit years. This is an obvious Year 2000 problem. Similarly, controls that lack Input Mask settings will use whatever input rule is dictated by the computer's Control Panel settingsùsuch a case is cause for concern. Makes sure to use input masks that require 4-digit year entry.
2. Because Microsoft Access is a database, there may be a temptation to store date/time data in text or number fields. This will cause Year 2000 problems and should be avoided. Access provides a Date/Time data type that correctly supports dates.
3. Use the Format function to ensure that dates displayed on datasheets, query results, forms and reports all use the Long Date format. This ensures that you always display the full four digits of the year.
4. The Calendar Control has shipped with Access 2, 95 and 97. It only stores years from 1900 to 2100. Under Microsoft Access version 2, two digit years are accepted. Under Microsoft Access 95 and 97, the Year property does not do the conversion that other parts of Microsoft Access does, so a year property of <1900 is considered invalid. This is a good thing because it forces the use of four digit years when using the Year property. However, the control does accept dates in the Value property with two digit years. So you must examine the use of Calendar controls for potential Year 2000 issues.
5. If you are using Microsoft Access 95, you may run into the situation where a user has unknowingly updated their OLE Automation Library, changing the rule for century assumption. See the section entitled "How Microsoft Products Assume Centuries" for more information.
6. Check all validation rules used on date/time fields to ensure that they correctly work with four digit years in the 21st century.
7. Table indexes can be created on date/time fields. Identify all potential issues associated with such fields that may contain incorrect century information.
8. Queries can group and sort on date/time fields. These need to be examined. Queries also support aggregate and functions that can operation on date/time fields. These are Sum, Avg, Min, Max, Count, StDev, Var, First and Last.
9. The Domain Aggregate functions available in Access can work on date/time fields. These are DAvg, DCount, DLookup, DFirst, DLast, DMin, DMax, DStDev, DStDevP, DSum, DVar and DVarP.
10. Reports can group and sort on date/time fields.
11. The Data Access Objects (DAO) programmatic interface to the Microsoft Jet database engine provides LastUpdated and DateCreated properties to show when structural changes occurred. These fields use compliant date/time fields for storage.
12. If you use Microsoft Access in multiple-version environments, there are additional issues to consider. Imagine a scenario where your application is deployed in two databases, an "application" database that contains all queries, forms, reports, macros and modules, and a "data" database that resides on the network. Now complicate issues by having the application database installed locally on user machines with attached/linked tables providing access to the data database on the network. Finally, imagine that some of your users are using a Microsoft Access 2 version, some are using an Microsoft Access 95 version, and some users are using an Microsoft Access 97 version.
    Because of the differences between each version, you could have multiple data entry operators seeing completely different results when your application is run. In fact, up to three completely different rules for determining centuries could be at work.
    If you are running in a mixed version environment, you must understand how each version of Microsoft Access interprets centuries. Then, scan your application's logic to ensure that each version's "application" database is in sync with the others.
13. Microsoft Access supplies import/export functionality through the File, Export menu item, and through the TransferText action. Using these facilities, you specify the file to use and various options. One of these options is "Four Digit Years". If this option is turned off, date being imported or exported is stripped of its century information.
    To address this issue, you need to ensure that users never have the option of deselecting the "Four Digit Years" checkbox. The alternative is the use the capability to save Import/Export settings as specifications. The application's developer should set up the specification, ensure that the "Four Digit Years" option is turned on, and from there on out the application should use the saved specification.
    If follows that as part of the certification process, you need to examine each saved import/export specification to ensure that the "Four Digit Years" option is turned on.

Microsoft Excel

1. Microsoft Excel treats 1900 as a leap year, even though it isn't a leap year. This was a design decision based on the desire to be compatible with Lotus 1-2-3, which originally introduced the (incorrect) identification of 1900 as a leap year.
2. The most common date format in Microsoft Excel is the Short Date format as defined by the Windows Control Panel. This format cannot be relied upon to show the full four digits of the year.
3. The rule used for assuming centuries on two digit years differs between Microsoft Excel 5, Microsoft Excel 95, version 7 and Microsoft Excel 97, version 8. In environments where different versions of Microsoft Excel are in use on shared data, this can cause problems.
4. If you record a macro that includes date entry, the macro will only record the date information according to the Windows Control Panel Short Date setting, which results in a two digit year when the macros is played back.
5. Defined names store references only as text strings. Since they do not store dates as serial values, they are vulnerable to century issues when a two-digit year is specified. Using defined names in this way is also problematic because the use of a date format with an order other than month-day-year will cause miscalculations. Recommended usage is to define the name referring to a cell containing a serial date, which avoids both of these problems.
6. You should avoid storing two digit dates in external formats that only support strings. For example, the TXT, DIF, CSV, and PRN formats cannot correctly store or represent two digit dates, since they deal only with strings.
7. Microsoft Excel supports Visual Basic for Applications (VBA) which uses the OLE Automation Library (OLEAUT32.DLL) for determining centuries on two digit years. Because Microsoft Excel does not use the OLE Automation Library, and VBA does, this can cause a mismatch when you pass two digit years between Microsoft Excel and VBA. To solve this, always include the full four digits of the year in such applications.

Microsoft Outlook

1. Microsoft Outlook uses two different windowing techniques based on the type of data being entered. For scheduling of tasks, events and meeting events, the window includes 30 years back from the current date and 70 years forward. Birthdays in the Contacts part of Outlook use a different window because birthdays are usually biased towards past years. When you enter a two-digit year in the Birthday field, the window is between ninety-five years back and five years forward from the current date.
2. An issue exists with Microsoft Outlook 97 you should be aware of. If a scheduled event spans the century boundary, the event will not be handled correctly. To fix this problem, obtain and install the update OUTLLIB.DLL available from Microsoft at http://support.microsoft.com/support/kb/
   articles/q181/3/51.asp. The update file is version 8.03. You do not need this file if you use Outlook 98.
3. Internally, Microsoft Outlook evaluates dates as true date/time information, not as strings. However, your custom solutions using forms, you should check for issues where two digit years are used.

Microsoft Word

1. Most features in Microsoft Word that rely upon dates use an internal 32-bit integer storage scheme that correctly handles dates and years. However, you can type dates into a document, or import date data from another application that results in dates stored as strings. When a date is stored as string, Microsoft Word cannot correctly interpret it as a date. An example of this problem is a table that is sorted by a column that has string dates--the sort will not be correct. Additionally, dates inserted with the Insert Date/Time command are placed in the document as text.
2. Microsoft Word version 6 and Microsoft Word 95 version 7 use the following rule to determine the century for two digit years: The two digit year "00" is interpreted as the year 2000, all other two digit years are interpreted as being in the 20th century. This rule is used by Microsoft Word when performing a table sort, and when using Date formatting (picture switch) of Quote Fields.
3. Microsoft Word 97 version 8 uses the following rule to determine the century for two digit years: Two digit years from 00 to 29 are assumed to be in the 21st century, all others are assumed to be in the 20th century. A date window of 1930-2029 is used when interpreting two digit year when using the Date formatting (picture switch) of Quote fields.
4. Saving a document to an earlier version of Microsoft Word, or upgrading an older document to a newer version has no negative effect on dates within a document. Note that all date field information and file properties are retained and correctly recognized.
5. Microsoft Word version 6 has a built in File Find utility. Using the Advanced Search capability of this utility does not allow the input of four digit years. Because all years are converted to the 20th century, with the exception of "00" which is converted to 2000, you cannot enter dates outside the 20th century in the Advanced Search dialog, other than 2000. This issue does not exist from version 7 (Microsoft Word 95) onwards.
6. Custom formulas, macros and code within a document that deal with dates need to be examined for potential Year 2000 issues.

As you can see from the material presented in this paper, certifying your applications for the Year 2000 involves a number of tasks. In addition to the steps listed here more information is available from the Microsoft Year 2000 Resource Center at http://www.microsoft.com/technet/year2k/.

<< 1 2 3 4 5 6 7 8 9 10 11 12 13 14 >>

This site is being designated as a Year 2000 Readiness Disclosure and the information contained herein is provided pursuant to the terms hereof and the Year 2000 Information and Readiness Disclosure Act.