This report applies to:
Introductory, Enterprise, Learning, Professional, and Standard editions.
Operational Range for Data: 1930 through 2029 using 2-digit shortcuts or user configurable.
Czech, Hungarian, Polish, Portuguese (Brazil), Romanian, and Russian versions contain US software.
Developing Year 2000 Compliant Software
How the product runtime handles dates:
Visual Basic 6.0 stores year-dates internally as 4-digits.
Two-digit shortcut handling:
The first 2 digits are assumed according to a specific rule in cases where only 2 digits are supplied for the date.
The rule is:
2-digit dates between 00-29 are assumed to occur in the 2000s (2000-2029).
2-digit dates between 30-99 are assumed to occur in the 1900s (1930-1999).
NOTE: This string to date conversion is done by OLE-Automation. Starting from the version of OLE Automation shipped with Visual Studio 6 (Fall 98), OLE-Automation (32-bit and beyond) will allow the user or administrator to set the 100-year window for parsing 2-digit dates. (The default will be as stated above, 1930 - 2029).
Outlook Express 4.01 date handling:
Outlook Express 4.01 (OE) is included with, but not a requirement forVisual Basic 6.0. If Outlook Express 4.01 receives an IMAP mail message or a News message with a 2-digit year as the sent date, the date can be misinterpreted under certain conditions. If the 2-digit year is anything other than 99, OE will assume the century value is the same as the current century. If the current year is 2000, and a 2-digit date is received as 97, then the year will be interpreted as 2097. However, there is one special case when different logic is applied. If the 2-digit year 99 is received and current year is a multiple of 100 (e.g. 2000), the year will be interpreted as the current year plus 98 (e.g. 2098). You can find more information about this in the Internet Explorer (32-bit) 4.0x Year 2000 disclosure document.
Recommended practices to develop year 2000 compliant applications with this Development Tool:
The product has known issues when dates are stored as strings. It is recommended that all dates are stored using Date data type as opposed to strings.
User-defined functions are a prime area of date handling errors. A poorly written function may lead to problems.
Dates that are stored as strings can also be a problem if there is an error in the information. Visual Basic will interpret a string as a date if, by rearranging the month/day/year order, a valid date can be found.
For example, both 3/30/98 (March 30, 1998) and 87/3/1 (March 1, 1987) are valid dates even though the month/day/year order have changed. For more information on which occasions might result in a date conversion error, please see the OLE Automation compliance document
For more information, please refer to the white paper, "Developing Y2K Compliant Applications with Visual Basic"
Common development errors dealing with year 2000 date issues:
Please refer to the white paper, "Developing Y2K Compliant Applications with Visual Basic"
Other design time issues to be aware of when using this tool:
If the following products or technologies are installed, they should be updated to ensure proper functioning:
Oracle Issues
There is an issue regarding 2-digit year parsing in the Visual Database Tools when connecting to an Oracle database with a system configured for 2-digit year format. If the year entered into the Grid PaneÆs Criteria cell is between 2029 and 2000 (the system default 2-digit year window for year 2000 dates) the date will be converted by OLEAUT32 into a 2-digit value when parsed into the SQL Pane. Oracle will interpret this as a year between 1929 and 1900.
The recommended work-around for this is to set your systemÆs Short Date format to include a 4-digit year.
A design-time update to the Visual Database Tools that addresses this issue is available for download as a part of Visual Studio 6.0 Service Pack 3.
Testing guidelines and recommendations:
Chapter 9 of Visual Basic documentation on MSDN has several examples of how to test for Year 2000 problems in Visual Basic applications. This is available on http://msdn.microsoft.com/library/books/advnvb5/html/Ch09.htm
Users testing applications written in Visual Basic should be especially careful to test the following problem areas:
|
User-defined functions: Many applications contain user-defined functions written in Visual Basic to deal with dates in various ways. Many of these functions store date values as strings. Manipulating these values improperly can result in date handling errors that are outside of the scope of the testing that was done at Microsoft on the Year 2000 issue. |
|
The date usage error described above can cause problems if an error handling routine is meant to catch improperly entered dates. Since Visual Basic rarely generates an error when a string date is used as an input, an error handling routine is unlikely to be called. In this case the proper programming technique would be to validate the data using code instead of relying on a runtime error to signal an improper date. |
Code Example:
The following example illustrates the date window in action with various input dates.
Sub TestDate()
Dim MyDate As Date
MyDate = "1/1/00"
Format MyDate, "mm/dd/yyyy"
MsgBox MyDate
End Sub
|
MyDate input |
Expected behavior |
|
1/1/00 1/1/1 1/1/9 1/1/2000 4/1/98 10/24/29 7/4/30 2/29/00 2/29/1900 |
1/1/2000 1/1/2001 1/1/2009 1/1/2000 4/1/1998 10/24/2029 7/4/1930 2/29/2000 error- Type mismatch (1900 not a leap year) |
For more information, please refer to the white paper, "Developing Y2K Compliant Applications with Visual Basic"
