Classic VB - How can I handle different locales?
One of the things that often goes unnoticed are the locales. VB uses current computer locale settings with several in-built functions that have involvement with strings. What this means is that you can't assume you always get the same data on every computer. This can lead to problems.
A classical example of this is creation of dates from strings. One of the simplest examples is this:
Code:
MsgBox CDate("12/01/2007")
Now which date is this? Is it the 1st of December 2007 or 12th of January 2007?
The answer depends on what locale your computer is. A USA based locale tells you it would be the 1st of December. However, several European locales (such as Finnish and English) would tell you that date is 12th of January 2007. Internationally speaking the former would be in a minority.
What this means is that if your code relies too heavily on assuming the first value is the month and the second value is the day, it wouldn't work on many countries in the world. In this specific case one could workaround the problem by using international standardized date format (2007-12-01 is always 1st of December), but the best way is to use the DateSerial function to create a date.
There are other cases when you will have problems with numbers. Many data conversion functions work on locale. Format$, CCur, CDbl, CSng and CStr are all locale aware. Try this:If you don't get an error, your computer locale uses comma as a decimal point. But if you get an error, you're on locale that uses period as a decimal point. The same applies the other way around, using period will raise an error on most non-English locales. With Val function, however, you can always use periods. It doesn't work with commas on any locale.
There are also some less known functions that can give you interesting behavior. For example, Weekday function isn't locale aware: it always assumes Sunday to be the first day of the week. However, WeekdayName function is, by default, locale aware. This means that if the current locale has different first day of the week (such as Monday), you get unexpected value out of WeekdayName if you just go ahead and give it the output value of Weekday. The way to go around this is to explicitly tell WeekdayName that Sunday is the first day of the week.
So what are the solutions?
Number to string: Use Str$()
String to number: Use Val()
String to date: avoid automatical coercion, parse input data (using Split for an example).
Date to string: if you always want a certain format, you have to construct it yourself. Otherwise you may use coercion.
These are what you should use when handling data internally. For user input you might wish to allow data input using whatever they prefer; or even better, skip the entire problem by providing custom input methods that can't go wrong.
Note: this was mostly written in an empty moment at work, thus I didn't have the time to go into perfect detail. If you have something to add, go ahead and do so.
