This post originated from an RSS feed registered with .NET Buzz
by Paul Vick.
Original Post: U.S.-centric dates and localized languages
Feed Title: Panopticon Central
Feed URL: /error.aspx?aspxerrorpath=/rss.aspx
Feed Description: a blog on Visual Basic, .NET and other stuff
Bill whinges a bit about the fact that date literals in VB are expressed using the U.S. date format, which is (of course) different that what most of the world uses. It's a legitimate gripe, but there's not much to be done about it. The cardinal rule that we follow with the language is that the current locale settings of a machine should never affect the compiler's output. Thus, everything expressed in the language that's processed at compile-time has to be in one canonical format and cannot be locale-dependent. And, of course, somewhere back in the mists of time when the canonical format was chosen, it just happened to be the format of the home country of the software... (This is also why you can't do string conversions in constant expressions - string conversions are locale sensitive.)
It's true, though, that the IDE used to be much more permissive about what it accepted as a date literal that you typed in (and which it would then convert to U.S. format). When we moved to .NET, we stopped using VarBstrToDate to convert strings that were input from the IDE and instead started accepting only legal canonical date strings. I don't exactly remember why it was we did that, though...
I will add that VarBstrToDate is a very, very, very scary piece of code. As Greg Low notes in the comments on Bill's entry, the old COM date conversions routines (on which IsDate is based) will do some truly wacky things. During the year and a half that I owned OLE Automation, I had to spend a good bit of time in the code for that routine and the finite state machine that it uses to try and recognize dates. Rather than just accepting the current locale, it has all kinds of weird logic to try and guess what you meant based on what's possible. So if you call the routine on “24/1/04” using the U.S. locale, it'll still parse it as January 24th, 2004 because it figured that the “24” is most likely a day value and that you were entering it in dd/mm/yy format. On the other hand, if you call the routine on “1/3/04” using the U.S. locale, you'll always get January 3rd, 2004. Scary stuff.
(I also heard tell that at one point back in the mists of Excel 5 days, the VB team experimented with allowing the language syntax to be localizable. So you could say, I don't know, “Por x = 1 a 5 : Escribe x : Siguiente x”, if you pardon my horrible Spanish. This turned out to be such a horrible idea that they quickly dropped it and never looked back. But supposedly the legacy lives on in OLE Automation and the fact that IDispatch takes a locale ID when converting names to DispIDs (i.e. so that you could have different method names for different languages). I can't vouch for the absolute truthfulness of this story, but it's one of those stories that's “too good to check.”)
Previous Topic
