Die neue Version der OLEAUT32.DLL (2.40.4512.1), die mit Windows 2000 geliefert wird, unterstützt nun auch den Thai-Kalender (zuvor wurden nur Gregorianische und Hijri-Datumswerte unterstützt, was auch den Möglichkeiten von VB entspricht). Es gibt dabei jedoch ein Problem, denn obwohl die Unterstützung in der DLL enthalten ist und MSDN die neue Fähigkeit dokumentiert, enthält das Platform SDK nicht die neuesten Header-Dateien, und daher lässt sich dieses Feature in der Praxis nicht nützen. Hier die Werte (die beim nächsten Platform SDK im Juli 2000 dabei sein sollten):
#define VARIANT_CALENDAR_THAI 0x20 // SOUTHASIA calendar support
#define VARIANT_CALENDAR_GREGORIAN 0x40 // SOUTHASIA calendar support
Ok, damit können Sie jetzt das Feature nutzen! Nun zum Bug:
Wenn Sie diese neue oleaut32.dll auf einer Thai-Maschine mit Win95/Win98/NT4 oder einem US-Windows 2000 mit Thai-Gebietsschema haben, dann erkennt COM, dass der Thai-Kalender zu nutzen ist. Leider verstehen VBA und VBScript aber nichts vom Thailändischen Datum, daher werden beide annehmen, dass ein Datum wie 9/4/2543 (die Thai-Entsprechung des. 9. April 2000) einfach ein sehr futuristisches Gregorianisches Datum sei! Plötzlich wird Code, der mit Datumswerten zu tun hat, agieren, als liege alles 543 Jahre in der Zukunft! Und wenn Ihre Anwender nicht Datumswerte eintippen, die 543 Jahre voraus liegen, dann werden diese falschen Daten von Ihrer Applikation verwendet.
Bei Hijri-Datumswerten ist das Problem noch etwas schlimmer, weil diese ungefähr 600 Jahre hinter dem Gregorianischen Datum liegen. Das wirkt dann natürlich komplett daneben. Ich bin nicht sicher, wie VBA die Hijri-Datumswerte eigentlich rechnet, aber falls es dazu COM verwendet, dann wird das Quelldatum nicht richtig als Thai identifiziert, denn es scheint davon auszugehen, dass das o.a. Datum 5/1/1964 sei, statt des richtigen Hijri-Datums 1/5/1421. Das Fehlerpotential ist hier noch größer, weil das Datum für den Anwender völlig unverständlich sein wird (während ein Anwender mit Thai-Gebietsschema evtl. das falsche Thai-Datum noch interpretieren kann).
Ein echter Fix muss dafür sorgen, dass VBA genau das Datum nutzt, das COM zur Verfügung stellt, statt bloß 2 Kalender fest codiert zu akzeptieren, während COM jetzt 3 unterstützt. Ein Workaraound für den Bug besteht darin, die Funktion VariantChangeTypeEx aufzurufen, um ein Datum in einen Gregorianischen Datums-String zu konvertieren und umgekehrt einen Gregorianischen Datums-String wieder in ein Datum. Die Deklaration dieser Funktion und der relevanten Konstanten sieht so aus:
Private Const VARIANT_NOUSEROVERRIDE = &H4
Private Const VARIANT_CALENDAR_HIJRI = &H8
Private Const VARIANT_CALENDAR_THAI = &H20
Private Const VARIANT_CALENDAR_GREGORIAN = &H40
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
Sie können folgende Prozedur verwenden, um das zu testen (aber nur, wenn Sie die neue oleaut32.dll haben!):
Sub TestDateFormats()
Dim vSrc As Variant
Dim vDst As Variant
vSrc = Date
Call VariantChangeTypeEx(vDst, vSrc, 1033, VARIANT_CALENDAR_GREGORIAN, vbString)
Debug.Print "Gregorianisches Datum: " & vDst
Call VariantChangeTypeEx(vDst, vSrc, 1025, VARIANT_CALENDAR_HIJRI, vbString)
Debug.Print "Hijri Datum: " & vDst
Call VariantChangeTypeEx(vDst, vSrc, 1054, VARIANT_CALENDAR_THAI, vbString)
Debug.Print "Thai Datum: " & vDst
End Sub
Das Ergebnis wird z.B. so aussehen:
Gregorianisches Datum: 4/9/2000
Hijri Datum: 05/01/1421
Thai Datum: 9/4/2543
Um einen String in ein Datum umzuwandeln, nehmen Sie als fünften Parameter statt vbString einfach vbDate. Sie können den gleichen Code unter erfreulicheren Umständen auch dazu verwenden, Datumswerte aus verschiedenen Gebietsschemata zu interpretieren.
Der Bug ist natürlich schlimm bei bestehenden Anwendungen, die auf Thai-Maschinen laufen, weil ihr Verhalten sich dadurch ändert. Ich hoffe, Microsoft wird dieses Problem schnell lösen.
