Microsoft Year 2000 Readiness Disclosure & Resource Center

Visual C++ and the Year 2000

Visual C++ provides several mechanisms for proper date handling, display and manipulation. However, to gain a complete understanding of the Year 2000 compliance of specific versions of Visual C++, please examine the Product Guide in the Microsoft Year 2000 Resource Center: http://www.microsoft.com/y2k.

Beyond how Visual C++ and related tools and technologies handle dates, it is obviously critical for you to understand how your own code uses, or misuses, dates. But verifying and fixing date issues in a software system can be a substantial undertaking. Within the Year 2000 community there has evolved a consensus as to the steps to perform, which are briefly reviewed below:

Stage 1: Inventory. Identify hardware and software that use, generate or change dates.

Stage 2: Assessment. Determine what needs to be fixed.

Stage 3: Remediation. Make the fixes.

Stage 4: Testing. Test the fixes.

Stage 5: Implementation. Put the fixes into production.

These steps apply regardless of the languages and platforms used.

Stage 1: Inventory

Create a system inventory: A detailed inventory is one of the best tools for estimating effort. Armed with the number of systems and their related metrics (even simple metrics such as "Lines of Code"), you can produce an estimate of the effort required to fix Year 2000 problems.

Generally speaking, the inventory should include such items as:

• Off-the-shelf components: You should review off-the-shelf systems and applications that have been purchased externally. In particular, consider any third-party custom controls (VBXs, OCXs, DLLs, and so on) that might include date processing. Calendar controls are an obvious candidate.
• Internally built applications: You or your company may have many small in-house applications for a variety of purposes. These applications are potentially dangerous because they might have been built "on the quick" and therefore might not have been subject to the usual quality control measures.
• Operating systems: Regardless of the operating systems currently used within your company (including Microsoft Windows 95, Windows 98 and Windows NT), you still need to be certain (verify) that the Year 2000 problem will not adversely impact your software.
• Databases: Your Visual C++ systems might interact with any number of databases ù local and shared databases, client/server databases, and so on. You need to ensure that any data processing that includes date values in these databases will function as expected into the Year 2000.
• BIOS for PC systems: Certain models of PCs will reset the clock date to 1980 if they are turned off before the turn of the century and then back on again after the turn of the century ù and donÆt assume newer machines are free from Year 2000 issues.
• Interfaces to other systems. Depending on the nature of your system, your programs might read data generated by other systems, or write data to be read by other systems. This may include interactions with systems belonging to other companies, government agencies, etc. The Year 2000 implications of these interactions should be considered.

State 2: Assessment

After you have completed a Year 2000 inventory of your computing systems, you are in a position to develop a rough estimate of the size and scope of the problem at your company so decisions regarding priorities can be made.

• Identify date-critical systems: Using the system inventory as a starting point, examine the program specifications or code for each component and identify those critical applications whose functionality relies on the accurate processing of date values.
• Identify required skill sets: Your system might have been developed using programming techniques for which skills are not commonly available, such as DDE. Be sure to identify the programming skill set that will be a minimum requirement to work on your systems.
• Complete a pilot project: Plan and implement a pilot conversion project on an existing system. This rehearsal will help to establish cost, time, and other resource estimates for future planning. For this pilot project, try to use a typical project that represents the norm.
• Produce estimates: Using feedback from the pilot project coupled with the data retrieved from the system inventory, calculate the estimated time and cost of completing the conversion project across all systems. If possible, calculate the time and cost per system, application, module, and line of code. All of this data will assist you or your management to allocate resources to the project.
• Create a conversion schedule: Using the data and metrics collated so far in this stage of the project, define an overall schedule for the project. As appropriate, ensure that the plan interacts with any planned maintenance releases, or other functional upgrades, such as support for the euro.
  When planning your schedule, donÆt forget to take into account your systemÆs "event horizon" (how far into the future it uses dates.)
• Create a testing strategy: Depending on the number of systems throughout your company, you could be facing possibly tens or even hundreds of conversions. In an attempt to reduce the duplication of effort, you should produce a testing strategy detailing all known conditions that could be affected by the Year 2000 problem.

Stage 3: Remediation

During the remediation stage you correct your code. The first task of this stage is to identify which areas of the system require modification. You're searching for any piece of code that even remotely looks like it could be involved with dates, including variables that are acted on by date functions and other variables that the values of those variables are assigned to.

Here are some general suggestions of problematic code to look for. (Later in the article are some code examples):

• Code that assumes 2-digits. This includes code that performs two-digit year arithmetic.
• Magic Dates: Some systems use special "sentinel" dates to indicate certain processing boundaries, such as 00/00/00, 9/9/99 or 12/31/99.
• The Year 2000 day-of-the-week problem: If a system defines "01/01/00" as January 1, 1900, any system that relies on the day of the week will interpret this day as a Monday ù when January 1, 2000 is a Saturday.
• 2000 as a leap year: Since 1900 was not a leap year, but 2000 will be, then whether "00" means "1900" or "2000" also determines whether "00" is a leap year or not. (See a suggested IsLeapYear() function later in this paper.)
• Dates in keys: Some database tables and data files use a date as the key for a record. If the date format of a database table or file doesn't include the century digits, unexpected results may occur when a user attempts to retrieve records based on a date past December 31, 1999.
• Dates in files and databases. Look for columns in your database that either display externally or store internally dates with only two digits for the year part. Obviously, the date format depends on the makeup and structure of your database.
  Be aware that it is possible for a database to store dates internally as four digits for the year part but to display them with two digits. If this is the case, you might need to include or modify a format function.
• Dates in keys. Look for record fields and table columns that have date values as part of the key. This technique is common in data entities used for storing time-related activities such as deliveries and appointments. If the date part is stored in a key with two digits for the year, unexpected results could occur in the Year 2000, particularly when the keys are sorted.
  A related problem occurs when a two-digit year is embedded in an account number, for example.
• Dates in input & output. Any date entry controls / fields should be considered. If they permit the entry of 2 digit years, how do they interpret year "00"? Or year "10"?
  If the system clock is set to a date in the 1900s, can the user enter dates in the 2000s ù and vice versa?
  If the system produces reports (hard-copy or electronic) that include dates, changing the format to four year digits could have the residual effect of wrapping or truncating text, or obscuring adjacent fields.
• Imported & exported dates. If your system imports data from other programs, or exports data to other programs, have changes in the date format been accounted for?

Stage 4: Testing

Even if you don't convert any code, you should test your systems from end-to-end to ensure that they are Year 2000 compliant. This may vary depending on the circumstances, but usually youÆll need to test your system in three different environments:

Regression test of today's production environment: Having made changes to your current system, make sure systems function as expected for the current time frame. In other words, ensure you havenÆt broken any existing functionality with your code changes.

Future date testing: Having verified that your system functions correctly in the present, you'll need to test your system's ability to cope with dates on either side of the Year 2000. The particulars for this test will depend on the nature of your systems.

Running your system in the future: Before setting your systemÆs clock forward, carefully consider the possible consequences: passwords may expire, "old" mail and records may be purged, software licenses may "expire," etc. If you are running your production and test code on the same machine, you run the risk of crashing your production system. ItÆs far safer to run your tests on a separate machine. Also, if the test system is connected to a network, there is also the possibility of unforeseen interactions between the test machine and other machines on your network. Be sure to do a full backup first.

The final test involves gauging the ability of your systems to function in and beyond the Year 2000. Set your system date to some time beyond 2000. If your system processes historical information, you should have test conditions in which you've set your system clock beyond 2000 and test dates before 2000.

Leap years: Be sure to test 2/29/2000 and 3/1/2000.

Year 2000 Testing Checklist

General Considerations:	Use a separate system for testing Isolate the test system from the network during the test Back up everything before the test See if Year 2000 date-simulation tools can provide an isolated testing area for your server Be careful setting the date ahead: data sets, passwords, user IDs, and product licenses may expire; e-mail may be deleted Turn off any programs that startup automatically when the system is powered on Do not share data sets between the test and production system or network Beware of scratch files or temporary directories which are set for deletion after a year or some other interval. You may inadvertently delete files Be careful not to delete e-mail accidentally Set an official point on a database to roll back to
Before the test:	Stop any pending processes Shut down and reboot the system Perform a complete backup Disallow logons during the test
After the test:	Shut down and reboot the system Set the date correctly Restore from the complete backup Allow logons
Recomendations for testing:1
	Beginning of the year:	1/1/1999 1/1/2000 1/1/2001
	End of year:	12/31/1998 12/31/1999 12/31/2000
	Leap year:	2/28/2000 2/29/2000 3/1/2000
	First fully 8-digit date:	10/10/2000
	Date rollover (power off and power on):	Set date to 12/31/1999 at 11:55 PM; ensure that the date and time roll over correctly (power off and power on)
	"Magic" sentinel dates:	1/1/99 9/9/99 9/10/99 12/31/99
	Date crossing test:	12/31/1999 to 1/1/2000 2/28/2000 to 2/29/2000 2/29/2000 to 3/1/2000 12/31/2000 to 1/1/2001
	What to look for:	Dates embedded as part of other fields Dates used for sorting Dates used as part of a file name Dates used to trigger another process (e.g., deleting old e-mail) Processes that are triggered by dates (e.g., routine maintenance forecasting, expiration dates, weekly and monthly processes) Validate external system interfaces or file exchanges: If date is expanded to 4-digit year be sure that a file exchange test is completed If date is not expanded, agree with your other party on data window for century

¹   This is a suggested list and is not assumed to be comprehensive, instead it identifies some of the most common causes of Year 2000 issues. Your code may require additional testing with other dates or parameters.

Stage 5: Implementation

Don't expect to put the software back into the production environment and have a fully functional system on the first try. The earlier you can get the software up and running, the more time you'll leave yourself to fix the inevitable problems.

Finally, finishing up your Year 2000 compliance effort might include updating your documentation, help files and training materials to reflect any user-interface changes.

<< 1 2 3 4 5 >>

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.