Date quirks

Before looking at each intrinsic function, I’ll address a few quirks common to most of Visual Basic’s date functions.

Regional settings The first of these funnies involves exceptions in the way that Visual Basic determines whether or not a given date is valid. The format of the date argument must adhere to a predefined set of rules. This exception is true regardless of your regional settings. For example, suppose your long date format defined in the regional settings looks something like “ddd, dd MMMM, yyyy.” This means that any date used as an argument to Visual Basic’s Format function with the format Long Date will end up looking something like “Sun, 06 October, 1996”. So far, everything is perfectly valid and aboveboard. Now try using this formatted date as an argument to one of Visual Basic’s intrinsic date functions, such as CVDate or CDate, and see what happens. You will receive an error 13, “Type Mismatch.” In short, Visual Basic does not like overcustomized dates.

Note Although this isn’t strictly a Year 2000 issue, you should try to avoid using region-specific date formats, such as Format$(Now, "mm/dd/yyyy"). You never know when your code might turn up in a foreign country. It’s always better to use the standard Visual Basic date formats, such as Format$(Now, "Long Date").

As far as I’ve been able to tell, if your long date format in the regional settings has a value for weekday (that is, Monday or Mon), or if there is any value in the date separator field in the Date property page of the Regional Settings Properties property sheet (such as a comma or a slash), Visual Basic will not recognize any date expression formatted as a long date. As an example of this, try changing your long date format to “ddd, dd MMMM, yyyy” and running the following line of code:

MsgBox CDate(Format(Now, "Long Date"))

Visual Basic will give you an error 13 because it does not recognize the date as valid even though your system settings do recognize the date format.

The following long date formats will be recognized in Visual Basic:

The following long date formats will not be recognized in Visual Basic:

Obscure regional settings While researching the various date functions and their relation to the system settings, I came across two quirks, which both appear to be unique to Visual Basic 3. The CVDate and DateValue functions do not like any regional setting in the order year, month, day. If your short date regional setting is in this order and your long date setting isn’t (or vice versa), Visual Basic 3 will not recognize as a valid date any date expression in the long date format.

This quirk can be additionally demonstrated by trying the IsDate function on a long date expression while the regional settings reflect the conditions above. For example, try the test on the following page.

1. Change your short date setting in your regional settings so that the order of parts is YMD.
   
   
2. Change the order of the long date regional setting to anything but YMD.
   
   
3. Try the following line of code:

MsgBox "The date is " & CVDate(Format$(Now, "Long Date"))

You should get a “Type Mismatch” error. If you try the DateValue function, you’ll receive an “Illegal Function Call” error. If you try the IsDate function on the date expression above, it will return FALSE.

Another problem along the same lines is the use of a medium date format when the short date regional settings order is YMD. Visual Basic will not recognize as a valid date any date expression in the medium date format when your short date regional settings order is YMD. If you alter your regional settings to the above condition, the following line of code will error with a “Type Mismatch:”

MsgBox "The date is " & CVDate(Format$(Now, "Medium Date"))

As with the previous quirk, the DateValue function will error with “Illegal Function Call” and the IsDate function will return FALSE.

Documentation This issue is slightly sillier; nonetheless, I have met people who were confused by the wording of certain documentation. Some documentation indicates that certain intrinsic Visual Basic functions will convert an expression to a date. Don’t be misled by this statement; most functions will return a value but will not alter the original value (used as an argument) in any way. This should really go without saying, but for the benefit of people who take the documentation literally, it’s worth keeping in mind. For instance, consider the following example:

Dim dteStartDate As Date
Dim sUserEntry As String
sUserEntry = "9/10/96"
dteStartDate = CDate(sUserEntry)

The argument to the CDate function (sUserEntry) is not converted, and its value does not change. Instead, the result of the CDate function is assigned to the dteStartDate variable.