My Web-based application (like most) follows the browser locale to format dates.
So if you configure British English as the preferred language in the browser, the app will display dates in "DD/MM/YYYY
" format.
Now QTP (ok, it´s VBScript that is the culprit) does not know about this. It strictly follows the local machine´s locale settings.
Unfortunately, that means that if my local machine is configured to German locale, and the app is in English (because the browser is configured this way), VBScript´s DateValue
function will fail (because it expects "DD.MM.YYYY
" format.
So what is an elegant way to convert an AUT-displayed date value to a native VBScript date so I can do calendar calculations and checks on it?
Except for switching the current user´s locale to one that matches the browser´s language, I don´t see a solution which avoids having to write decoders/encoders for all kinds of locales myself -- which looks like a huge overkill to me.
For example, a DateValue
variant which lets me explicitely specify the locale to use would be great. Is there such a thing?
In general, its not just about dates, but every data item that is formatted differently depending on the locale (time specs, currency amounts, floats, ...).
While it is said (by Microsoft, see https://technet.microsoft.com/en-us/library/ee176965.aspx) that
GetLocale
andSetLocale
are usable only in WebPages, those functions are exactly what I was looking for. And they work within QTP.To convert a date value from the AUT (being a string) to a VBScript date value, I
GetLocale
to fetch and save the original localeSetLocale
to switch to the same locale as the browser´s (read from registry)DateValue
to convert the string to a native date (or use any other locale-sensitive routine)SetLocale
with the original setting to switch back to the original locale.Interestingly, QTP always starts a test´s execution with the system locale active -- even if the last test execution did leave behind a different locale set active.
See f.e. https://support.microsoft.com/de-de/kb/232158/en-us
Not sure about QTP, but the windows scripting host handles it via
SetLocale