{"id":94965,"date":"2016-12-19T07:00:00","date_gmt":"2016-12-19T22:00:00","guid":{"rendered":"https:\/\/blogs.msdn.microsoft.com\/oldnewthing\/?p=94965"},"modified":"2019-03-13T10:34:58","modified_gmt":"2019-03-13T17:34:58","slug":"20161219-00","status":"publish","type":"post","link":"https:\/\/devblogs.microsoft.com\/oldnewthing\/20161219-00\/?p=94965","title":{"rendered":"Why can’t VarDateFromStr parse back a Hungarian date that was generated by VarBstrFromDate?"},"content":{"rendered":"

A customer liaison reported a problem with date parsing. <\/p>\n

Ugh, date parsing. <\/p>\n

\n

The customer is receiving date information from a scanner that they want to parse. They are using the COle­Date­Time::Parse­Date­Time<\/code> method. The customer reports that clients in Hungary (locale 1038) are unable to parse dates. The call to COle­Date­Time::Parse­Date­Time<\/code> fails with false<\/code>. That method internally uses Var­Date­From­Str<\/code>, and calling Var­Date­From­Str<\/code> directly fails with the error DISP_E_TYPE­MISMATCH<\/code>. <\/p>\n

This problem is observed only for Hungarian. <\/p>\n<\/blockquote>\n

The customer included a demonstration program that calls methods on COle­Date­Time<\/code>, but I’ve stripped away the wrapper below, so we can focus on the problem better. <\/p>\n

\nLCID hungarian = MAKELANGID(LANG_HUNGARIAN, SUBLANG_HUNGARIAN_HUNGARY);\nDATE date = ...; \/\/ something\nBSTR str;\nhr = VarBstrFromDate(date, hungarian, VAR_DATEVALUEONLY, &str);\n\/\/ The call to VarBstrFromDate succeeds and returns something like\n\/\/ \"2010. 12. 05\". Now let's try to parse it back.\n\nhr = VarDateFromStr(str, hungarian, VAR_DATEVALUEONLY, &date);\n\/\/ The attempt to parse back to a date fails with DISP_E_TYPEMISMATCH.\n<\/pre>\n
The customer noted that this change in behavior was relatively recent. <\/p>\n
The reason is that the localization team in Windows 10 made a change to the date formats for Hungarian. In earlier versions of Windows, the call to Var­Bstr­From­Date<\/code> produced \"2010.12.05\"<\/code>. Notice the difference? <\/p>\n
The date separator changed from a period to a period followed by a space<\/i>. <\/p>\n
This highlights that culture data is not stable<\/a>. Any code that generates Hungarian-formatted dates will produce different results on Windows 10 compared to earlier versions of Windows. <\/p>\n
Of course, one should also note that the date formatting preferences can also be customized by the user at any time, so the statement is even stronger: Any code that generates locale-sensitive formatted dates may produce different results at any time, even within a single run of the program. <\/p>\n
So if your goal is to format the date as a string, with the intention of parsing it back, then you don’t want to use anything that is locale-sensitive. Instead, use a locale-insensitive format, such as ISO 8601. <\/p>\n
The customer said that they were getting the information from a scanner, but it wasn’t clear where the scanner was getting it from. <\/p>\n
If this is a timestamp generated by the scanner itself, then they should try to configure the scanner to generate timestamps in a locale-insensitive format. <\/p>\n
If the timestamp is coming from the document being scanned, then you need to work out who is generating the document. If the document was generated by the same program that is trying to parse the result back (which the sample code seems to be suggesting), then you should fix the program that generates the document so it uses a locale-insensitive format. For human readability, you could have it generate a locale-sensitive version of the date next to the locale-invariant version. On the other hand, if the document was generated by an external source, then you may want to implement a custom parser that handles the date format that the external source uses. <\/p>\n
And if you don’t know what date format the external source is using, then you’re kind of stuck. After all, a date of the form 12-05-2010<\/code> is ambiguous. It might be generated by somebody whose locale settings specify a date format of MM-DD-YYYY<\/code>, or somebody whose locale settings specify a date format of DD-MM-YYYY<\/code>. <\/p>\n
Okay, so we’ve addressed the customer’s problem of not being able to round-trip a date-to-string-to-date conversion. But why specifically does changing the date separator from “period” to “period and space” cause Var­Date­From­Str<\/code> to be unable to parse back a string that it generated itself? <\/p>\n
The string 2010. 12. 05.<\/code> parses back like this: <\/p>\n