| 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 FirstDayOfWeek and FirstWeekOfYear argument. | Current Century | |
|
4
(32-bit) |
Date |
CDate, Weekday, and DatePart updated to include optional FirstDayOfWeek and FirstWeekOfYear argument.
|
OLEAUT32 | DateSerial does not use OLEAUT32; it uses a current century window similar to 16-bit version 4. |
| 5 | Date | OLEAUT32 | ||
| 6 | Date | FormatDateTime, MonthName, WeekdayName | OLEAUT32 |
The basic split is between the 16-bit 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 complete lack of a built-in Date data type in the first version.
NOTE
The 32-bit implementation of Visual Basic 4 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. This is the only time in all the versions of Visual Basic that these functions might provide different results.
If you are migrating your code from Visual Basic 1 to Visual Basic 6, you will most likely have to deal with date storage based around Strings, with any manipulation logic having been hand-written. 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 just 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 and Visual Basic 3 will be more common than from Visual Basic 1. Here you might be lucky: when well written, code in these versions can be very 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. Just as with code from Visual Basic 1, you might have to work with code that stores dates in Strings. I still come across very recent Visual Basic 3 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 20th 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 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 implementation of this 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 current century.
There is no real difference between Visual Basic 5 and Visual Basic 6 in terms of date usage other than the additional functions and controls available to you in version 6.
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; however, these tools have not always been used. Even today noncompliant applications are still being produced.