Microsoft Year 2000 Readiness Disclosure & Resource Center

Developing Year 2000 Compliant Applications in Microsoft Visual Basic

A great number of developers are in the process of rewriting applications that were written in previous versions of Visual Basic. This section looks at the differences between the various versions of the language and some of the date issues you can encounter. The table below is a summary of the date-handling features of the different versions of Visual Basic.

Visual Basic version	Date data type?	New Functions	Date Window	Other Issues
1	No	DateValue, DateSerial, IsDate, Day, Month, Year, Weekday, Date($), Now, TimeValue, TimeSerial, Hour, Minute, Second, Time($), Timer, Format($)	1900-1999	No native date storage. Dates either stored as Strings or Doubles.
2	Variant (Type 7)	CVDate	1900-1999	.
3	Variant (Type 7)	DateDiff, DateAdd, DatePart	1900-1999	.
4 (16-bit)	Date	CDate Weekday and DatePart updated to include optional First DayOfWeek and First WeekOfYear argument	Current Century	.
4 (32-bit)	Date	CDate Weekday and DatePart updated to include optional First DayOfWeek and First WeekOfYear argument.	OLEAUT32	DateSerial does not use OLEAUT32, it uses a current century window similar to 16-bit version 4.
5	Date	.	OLEAUT32	.
6	Date	Format DateTime, MonthName, Weekday Name	OLEAUT32	.

The basic split is between the 16- and 32-bit versions of the language. If you are migrating your code from a previous 32-bit version of the language, the date logic will work unchanged. However, if you are moving from a 16-bit version, there are some differences. The most significant difference is the lack of a built-in date data type in the first version.

Note   The 32-bit implementation of Visual Basic 4.0 has a strange anomaly. In this implementation the DateSerial function does not use the same date window as the CDate and CVDate functions provided by OLEAUT32. DateSerial uses the same current century window as the 16-bit implementation of version 4.0. This is the only time in all the versions of Visual Basic that these functions might provide different results.

If you are migrating code from Visual Basic 1.0 to Visual Basic 6.0, you will most likely have to deal with date storage based around Strings and handwritten manipulation logic. The quality of this logic will very much depend on the original author, but it should always be treated with suspicion. It is guilty until proven innocent, because this code would have been written in the late eighties and early nineties, when the world was only starting to wake up to the Y2K problem. At the very least, the leap year logic will be suspect.

Migrating from code written in Visual Basic 2.0 and Visual Basic 3.0 will be more common than from Visual Basic 1.0. Here you might be lucky: Well-written, code in these versions may be Y2K compliant. The Variant data type did (and still does) store dates in the same format as the newer Date data type. These versions have the full complement of supporting conversion and manipulation functions. Unfortunately, there has been a real lack of awareness of the Variant typeÆs existence for use with dates. As with code from Visual Basic 1.0, you might have to work with code that stores dates in Strings. I still come across very recent Visual Basic 3.0 code that is not in the least bit year 2000 compliant (in some cases within compliance projects!).

If you have been lucky and the original author used the Variant data type, be aware of the original date window. These versions will always assume the twentieth century for ambiguous dates. Any code that relies on this behavior will be in for a surprise when ported to the latest version.

Visual Basic 4.0 is easier to migrate from than the previous three versions. This one supports the Date data type, and from my experience most code will have been written using it. Here the only issue is the date window. The 16-bit version uses a date window that assumes the current century for an ambiguous date. The 32-bit version uses the window provided by OLEAUT32, although at the time of this versionÆs release OLEAUT32 also assumed the current century.

There is no real difference between Visual Basic 5.0 and Visual Basic 6.0 in terms of date usage other than the additional functions and controls available to you in version 6.0.

In all cases, any code you port will be as good as the original authorÆs. We have had the tools to store and manipulate dates since version 3.0; however, these tools have not always been used. Even today noncompliant applications are still being produced.

What to Look Out for When Renovating Old Code

This section lists a few of the problems that can appear when youÆre updating existing code.

Sorting on dates

Noncompliant date formats will become readily apparent when dates are sorted. Take, for example, the YYMMDD alphanumeric date format: When this format starts finding dates with the year 00, they will be sorted before all other years. Sorting reports or displays on dates is not an uncommon feature of computer systems. This can generally be thought of as a cosmetic problem, but it can be a very visible barometer of more serious and far less visible problems.

Dates manipulated as strings

When reviewing code written in the earlier versions of Visual Basic, we often see date manipulations carried out on Strings. Take the following piece of code:

Dim dteMyDate As Date
Dim nYear As Integer

dteMyDate = Now

nYear = Val(Right$(Format$(dteMyDate, "Long Date"), 4))

If nYear > 1999 Then
MsgBox "Welcome to the Twenty First Century!"
End If

This will work, unless of course somebody has changed the format of the Long Date in the regional settings of Control Panel. If the original programmer was more enlightened, you might see something like this:

nYear = Val(Format$(dteMyDate, "yyyy"))

Here the programmer is explicitly stating the preferred format for the date to be used in. If you are lucky you might actually see the following code, which correctly avoids the conversion to a string altogether by employing theYear function of Visual Basic:

nYear = Year(dteMyDate)

Using the Find dialog box of Visual Basic to search on Long Date, Short Date,Mid, Right, Left, and Format can be revealing. The first example above, using Format$ is not uncommon.

Most of the compliance problems in Visual Basic applications can eventually lead back to the manipulation of dates as strings. This must be treated with extreme mistrust. Your first task when renovating this code must be to replace this code based around strings with the built-in date functions operating on Date data types.

Look for dates used as magic numbers

Magic number dates are date values that are used as a system indicator. Dates such as 9/9/99, 12/31/99, or 999999 are common examples. These might be used to indicate such things as records that never expire, locked or deleted records, or records that must always be displayed at the start or end of a list. They work fine until the magic date occurs, then all sorts of strange behavior can follow. Again, using the Find dialog box to search for these strings can be most illuminating.

Testing

Without a doubt, the Y2K problem has highlighted the importance of testing. Even if you donÆt convert any code, at the very least, testing all of your Visual Basic applications is recommended to ensure that they are year 2000 compliant.

If you have made changes, perform regression testing wherever possible, using the original test scripts for each application. If you donÆt have access to the original test scripts, I recommend that you attempt to test the functionality of the entire application, whether or not certain functionality uses date processing. This step is necessary because various changes at any level of the application could have a domino effect (for any number of reasons) on any other application functionality. Testing only the changes is not good enough.

Ensure that all test conditions and the results from all testing are well documented. The testing tasks and issues described in the following subsections might help you formulate your testing plan.

Test the user interface and third-party controls

As I have mentioned, calendar controls are at the top of the hit list for potential Y2K horror stories. So if your application uses a calendar, and even if you have a new year 2000 compliant version of that calendar, give it a good hammering. Test all conceivable scenarios. Leave no stone unturned. When testing the user interface there are a number of key dates you should test in as many different formats as possible. The table below shows a list of dates recommended for use in your testing.

Valid	Invalid	Ambiguous
Dec 31 1998	Jan 1 1999	Feb 29 1900
Jan 1 00	Feb 27 1999	Feb 28 1999
Feb 29 1999	Jan 1 99	Mar 1 1999
Sep 9 1999	Feb 30 2000	Feb 29 00
Dec 31 1999	Jan 1 2000	Feb 29 2001
Jan 1 29	Feb 28 2000	Feb 29 2000
Feb 30 2004	Jan 1 30	Mar 1 2000
Dec 31 2000	.	.
Jan 1 2001	Feb 28 2001	.
.	Mar 1 2001	Feb 28 2004
.	.	Feb 29 2004
Mar 1 2004	.	.

Test Data and Conditions

Testing for the year 2000 wonÆt be like any testing that youÆve done before. HereÆs why: To be 100 percent certain that your business can survive into the year 2000, you will need to execute three completely separate system tests. The tests will deal with three different sets of data, and more than likely (depending on the size of your organization), each of these three tests will be in a different testing environment.

Regression test of todayÆs production environment

Having made changes to your current system, your next task is to determine that all programs function as expected for the current time frame. In other words, you want to be certain that your business can continue to use its Visual Basic applications with no unexpected side effects.

In effect, this test will ensure that the systems work exactly as they did when they were originally built. At first this test might sound counterproductive, but itÆs no good announcing to the world that all your applications are Year 2000 compliant if they come crashing to their knees!

Future date testing

Having verified that your system functions correctly in the present, youÆll need to create a second set of test data that will test your systemÆs ability to cope with dates on either side of the year 2000. The particulars for this test will depend entirely on the business nature of your applications.

For example, suppose that your Visual Basic application maintains car insurance policies, which typically can have a life cycle of 12 months. YouÆll need to set your system clock to some time in 1999 and run your tests, this time looking specifically for the applicationÆs ability to process car insurance policies that will expire in the year 2000.

Your business might have a shorter future date requirement, such as a long-term car parking system that has a maximum life cycle of six months. In this case, you need to ensure that the system date is set to at least August 1999 so that you can adequately test processing into the year 2000.

And the list goes on. Make sure you thoroughly understand the future date capabilities and scope of your system. Then, run your system so that it is forced to process future dates that are at least in the year 2000, if not later.

Running your system in the future

The final test involves gauging the ability of your applications to function in and beyond the year 2000. Set your system date to some time beyond 2000, and run your original test scripts. DonÆt forget that if your system processes historical information, you should have test conditions in which you set your system clock beyond 2000, and then force your applications to look at dates before 2000.

Leap years

In all three of your system tests, include conditions that will force your application to process the last two days in February and the first two days in March. The year 2000 is a leap year, which means that February 29 2000 is a valid date. It is possible that during the development of your Visual Basic applications, a programmer might have manually calculated (incorrectly) that the year 2000 is not a leap year, so be sure to test for it.

Recommended system dates

If youÆre lucky (or wise), youÆll have already built automated testing procedures that donÆt require too much manual intervention. Otherwise, somebody is going to get sore fingers! In a perfect world, I would suggest running your complete system test against the following system date years: 1998, 1999, 2000, 2001, 2002, and 2007.

Change your system date

Before we get into the techniques involved in changing your system date, be warned! Some system resources and functions are date- and time-sensitive and might be switched on or off when you change the system date. Before changing your system date, make sure that you understand all of the consequences. Better still, consult an expert first.

The tests you carry out with regard to the system date serve dual purposes. Not only are you testing the ability of your applications to function correctly in the year 2000 and beyond, you are also testing how well your hardware will cope with the change. Although the hardware issue is outside the scope of this chapter, it is still an important concern.

In many cases, your system date will come from one of three places: as a date value in your database, from the clock on your server, or from the clock on your PC. Retrieving the current system date from the database is a wise move. If your Visual Basic applications do this, resetting your system date is simply a matter of changing the value in the database. But youÆll still need to test the ability of your machines to function in the year 2000. WeÆll look at the steps involved with that test in a moment.

If your applications retrieve the system date from the PCÆs clock and the PC is connected to a network, chances are that your workstation retrieves its system date from the server. In this case, you should definitely consult your network administrator about changing the system date. In order to change the system date without being affected by the network, you may try disconnecting the PC from the network. However, disconnecting it from the network will probably defeat the whole purpose of the exercise, especially with regard to testing the hardware.

If your system date is retrieved only from the PCÆs clock, your PC might not be able to set the clock beyond the year 2000. This is because the BIOS on some older PCÆs is not aware of centuries. Whatever the case, I recommend running the following two tests on your PC to assess your applicationÆs year 2000 functionality and your hardwareÆs capabilities.

System clock automatic update test

When the clock rolls over to start the year 2000, most of us will be popping party balloons, singing, and hugging loved ones. I expect very few office PCs will actually be turned on over the New YearÆs holiday (although it has been suggested that companies should leave them on just in case), and even fewer Visual Basic applications will be running. In the spirit of completeness, however, I recommend that you test to find out if your PCÆs clock will actually roll over. To do so, follow these steps:

1. Using the DOS DATE function, set the PCÆs date to 12/31/1999.
2. Using the DOS TIME function, set the PCÆs clock to 11:58:00.00.
3. Keep the power on.
4. Wait until the clock passes midnight.
5. Check the date to ensure that it is 01/01/2000.
6. Test your Visual Basic application (if appropriate).
7. Turn off the power.
8. Wait for a while.
9. Turn on the power.
10. Check the date to ensure that it is still 01/01/2000.
11. Just for good measure, test your Visual Basic application again (if appropriate).

System clock automatic update test after a power down

The more likely scenario is that on the evening of Friday, December 31, 1999,office workers will switch off their machines and go home and will return on Tuesday, January 4, 2000. To ensure that the PCÆs clock will successfully roll over to the correct date while the power is down, perform the following test:

1. Using the DOS DATE function, set the PCÆs date to 12/31/1999.
2. Using the DOS TIME function, set the PCÆs clock to 11:58:00.00.
3. Turn off the power.
4. Wait at least three minutes.
5. Turn on the power.
6. Check the date to ensure that it is January 1 2000.
7. Test your Visual Basic application (if appropriate).

There are countless more tasks and issues concerned with testing for year 2000 compliance. I hope the issues IÆve raised will set you on the path to creating the perfect test plan. The important thing is to be sensible about testing. Consider all possible scenarios, and donÆt cut corners.

Consider Third-Party Tools

With the deadline now looming dangerously close, companies are finding themselves working with very tight project deadlines in their migration and renovation projects. Time spent reviewing some of the available third-party tools can pay real dividends in your productivity. Tools such as Visual DateScope 2000 from Class Solutions Ltd. (http://www.themandelbrotset.com/) can provide you with the edge you need when it comes to meeting that deadline.

<< 1 2 3 4 5 6 7 8 9 10 >>

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.