Chinese - Simplified   Dutch   English - United States   French   German   Portuguese - Iberian   Spanish   Thai  


Usenet Posting #24 - Trigeminal Software, Inc. (English)

Subject: INFO: A bug with the new oleaut32.dll calendar support and VB, VBA, and VBScript
(Originally posted 4/09/00)

The new version OLEAUT32.DLL (2.40.4512.1) that ships with Windows 2000 has added support for the Thai calendar (previously it had only supported Gregorian and Hijri dates, which is all VB supports). There is an initial problem that although the DLL contains the support and MSDN documents the new capability, the platform SDK does not contain the latest header files, so you can't actually use the feature. Here are those values (which should be there for the next platform SDK in July 2000):
#define VARIANT_CALENDAR_THAI         0x20  // SOUTHASIA calendar support
#define VARIANT_CALENDAR_GREGORIAN	  0x40  // SOUTHASIA calendar support
Ok, you can use the feature! Now for the bug:

When you have this new oleaut32.dll on either a Thai Win95/Win98/NT4 machine or a US Windows 2000 machine with Thai regional settings, COM will recognize that the Thai calander is the one to use. Unfortunately, VBA and VBScript do not understand the concept of Thai dates, so they will both assume that dates like 9/4/2543 (the Thai equivalent of April 9th, 2000) is simply a very futuristic Gregorian date. Suddenly, any code you have to display dates is going to look like everything is 543 years in the future! And if your users do not type in dates that 543 years ahead, the incorrect date will then be used by your application.

The problem is slightly worse if you use Hijri dates, which are approximately 600 years prior to Gregorian dates. Everything will seem to be way off. I am not sure how VBA is actually calculating Hijri dates, but if they are asking COM to do it, they are not properly identifying the source date as being in Thai, since it seems to think that the date is 5/1/1964 rather than the proper Hijri date, 1/5/1421. There is even more potential for corruption here, since the date does not correspond to any date that a user would understand (as opposed to the Thai date, which presumably a user who has Thai regional settings would understand).

The real fix is obviously for VBA to have a mechanism for its date handling that uses whatever COM has available to it, rather than being hardcoded to accept only two date types when COM will now support three. To workaround this bug, you need to call the VariantChangeTypeEx function to convert a date to a Gregorian date string and a Gregorian date string back into a date. The declaration of that function and relevant constants are:


Declare Function VariantChangeTypeEx _
 Lib "oleaut32.dll" _
 (ByRef pvargDest As Variant, _
 ByRef pvarSrc As Variant, _
 ByVal lcid As Long, _
 ByVal wFlags As Integer, _
 ByVal vt As VbVarType) As Long
and you can use the following procedure (if you have the new oleaut32.dll only!) to test this out:
Sub TestDateFormats()
    Dim vSrc As Variant
    Dim vDst As Variant
    vSrc = Date
    Call VariantChangeTypeEx(vDst, vSrc, 1033, VARIANT_CALENDAR_GREGORIAN, vbString)
    Debug.Print "Gregorian date: " & vDst
    Call VariantChangeTypeEx(vDst, vSrc, 1025, VARIANT_CALENDAR_HIJRI, vbString)
    Debug.Print "Hijri date: " & vDst
    Call VariantChangeTypeEx(vDst, vSrc, 1054, VARIANT_CALENDAR_THAI, vbString)
    Debug.Print "Thai date: " & vDst
End Sub
The output will look like this:
Gregorian date: 4/9/2000
Hijri date: 05/01/1421
Thai date: 9/4/2543
To convert from a string to a date, simply specify vbDate in that fifth parameter instead of vbString. You can use this same code under more pleasant circumstances to help interpret dates from different locales.

The bug is obviously pretty bad for existing applications running on Thai machines since their behavior will be changed. I hope Microsoft addresses this one quickly.


Problems with this site? Please contact the
with your comments, questions, or suggestions.