It has not always been so invariant

by Michael S. Kaplan, published on 2006/08/27 20:51 -04:00, original URI: http://blogs.msdn.com/b/michkap/archive/2006/08/27/727607.aspx


The other day, Bill asked the following question:

Anyway, I have the following code:

    SYSTEMTIME st;
    memset(&st, 0, sizeof(SYSTEMTIME));
    st.wYear = 2005;
    st.wMonth = 9;
    st.wDay = 12;
    st.wHour = 12;
    st.wMinute = 30;
    DATE date;
    SystemTimeToVariantTime(&st, &date);

    VARIANT myVar;
    VariantInit(&myVar);
    myVar.vt = VT_DATE;
    myVar.date = date;
    VARIANT myStr;
    VariantInit(&myStr);

    HRESULT hr = ::VariantChangeTypeEx(&myStr, &myVar, LOCALE_INVARIANT, 0, VT_BSTR);
    printf("%S\n",myStr.bstrVal);


on Win2K, this will print:

    123000

on WinXP, this will print:

    09/12/2005 12:30:00

So my customer asks: "Is this a known issue?  Is there a work around that can be suggested?"

Some of you have read this post (which gives the exact date that the change to support the invariant locale was added to the Windows source tree), then you know the answer already.

In a nutshell, the invariant locale didn't exist until after Windows 2000 shipped.

So the behavior that is seen here is what you get when an unsupported LCID is passed (we have previously established that no one checks return values!).

For workrounds, picking any specific LCID here will do the trick. As long as you use a particular one consistently then the results will have consistency....

 

This post brought to you by (U+12d9, a.k.a. ETHIOPIC SYLLABLE ZU)


no comments

Please consider a donation to keep this archive running, maintained and free of advertising.
Donate €20 or more to receive an offline copy of the whole archive including all images.

go to newer or older post, or back to index or month or day