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's still an important concern, because without the hardware… say no more!
In many cases, your system date will come from one of three places: from 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 very wise move. If your Visual Basic applications do this, resetting your system date is simply a matter of changing the value in the database. That's all there is to it. But you'll still need to test the ability of your machines to function in the year 2000, and we'll look at the steps involved with that 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. There is one way of changing the system date without being affected by the network, and that is to disconnect the PC from the network. If you disconnect your PC, however, you 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, consider the fact that on some older PCs you might not be able to set the clock beyond the year 2000. This is because the BIOS doesn't know about centuries. Whatever the case, you should run the following two tests on your PC to judge both your application's functionality and your hardware's capabilities.
System clock automatic update test
In most cases, when the clock rolls over to start the year 2000, most of us will be popping party balloons, singing, and hugging loved ones (or as Mark Mayes said in the last edition, lying at the bottom of the garden caressing an empty bottle of vodka!). 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, you should test to find out whether your PC's clock will actually roll over. To do so, follow these steps:- Using the DOS DATE function, set the PC's date to 12/31/1999.
- Using the DOS TIME function, set the PC's clock to 11:58:00.00.
- Keep the power on.
- Wait until the clock passes midnight.
- Check the date to ensure that it is 01/01/2000.
- Test your Visual Basic application (if appropriate).
- Turn off the power.
- Wait for a while.
- Turn on the power.
- Check the date to ensure that it is still 01/01/2000.
- 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 all office workers will go home on the evening of Friday, December 31, 1999, having switched off their machines, and will return on Tuesday, January 4, 2000. To ensure that the PC's clock will have successfully moved on to the correct date while the power was down, perform the following test:- Using the DOS DATE function, set the PC's date to 12/31/1999.
- Using the DOS TIME function, set the PC's clock to 11:58:00.00.
- Turn off the power.
- Wait at least three minutes.
- Turn on the power.
- Check the date to ensure that it is January 1 2000.
- 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 your path toward creating the perfect test plan. The important thing is to be sensible about testing. Consider all possible scenarios, and don't cut corners.