Resolved Force US English culture

ALX

Well-known member
Joined
Nov 16, 2005
Messages
253
Location
Columbia, SC
Programming Experience
10+
I have made my VB application available to the entire US and it has been running without incident for several months, so I know there are no bugs in the basic code. Recently I have had a few people in India download the application and they have reported an error where the app parses the current date string. I really had not intended to make this app global in scale, but am thinking that I would now like to make it available to countries like India, where there is a large percentage of technically minded and English speaking people. The error occurs where the code is parsing a date into Day, Month and Year. It breaks it down by searching Now.ToShortDateString for the forward slash "/" to divide the date string into individual components. My best guess is that Windows, for the culture settings in India, is not using the forward slash within the date string. Does anyone have any insight on this ?
Also...
Rather than go through the entire code to redo any string references to a date, I'd like to force the app to use the English culture entirely as these users are already conversing in English. I'm thinking that the Assembly Information "Neutral Language" setting in VS will use the specified language only as a fallback if no resources for the current culture are found. Is this correct ? I admit that I had not set this Attribute and it was set to "none". I haven't had much luck with Google for this. Can anyone provide some guidance ???
 
OK... I stumbled across the solution so I can answer my own questions.
For those who may need to know... The date in the Indian culture does not contain any forward slashes but rather hyphens.
Also, the culture can apparently be set with the following code...
VB.NET:
Dim ci As CultureInfo
ci = New CultureInfo("en-US")
CultureInfo.DefaultThreadCurrentCulture = ci
 
Last edited:
That's a bad solution to a problem that you created in the first place. The proper solution is to not do this at all:
It breaks it down by searching Now.ToShortDateString for the forward slash "/" to divide the date string into individual components.
The DateTime structure already has numeric properties for the day, month and year so you should be using them:
VB.NET:
Dim currentDate = Date.Now
Dim currentDay = currentDate.Day
Dim currentMonth = currentDate.Month
Dim currentYear = currentDate.Year
NEVER convert between Date and String unless you absolutely need to, which means when parsing input from a file or the like or when outputting to a file or the like.
 
Of course you are right again, JM. The reason I am converting the date to a string is that the date is eventually encoded. It is used to monitor the program's installation date to over see the free trial period and can not be a variable sitting in a file that a user could recognize and modify to beat the trial time restriction. It also needs to be a specific number of characters... (5 is replaced with 05). Although, using the .Day, .Month and .Year from the date certainly solves any cultural parsing issues. As always... Thank You ! You have a gift for being able to see through the BS.
 
As opposed to go through the whole code to re-try any string references to a date, I might want to compel the application to utilize the English culture totally as these clients are as of now speaking in English. I'm believing that the Assembly Information "Impartial Language" setting in VS will utilize the predefined language just as a backup plan assuming no assets for the ongoing society are found. Is this right ? I concede that I had not set this Attribute and it was set to "none". I haven't had a lot of karma with Google for this. Could anybody at any point give some direction ???
 
Back
Top