CODEWITHSUNDEEP
c#.netwinformsdatetime
NitroFrost
NitroFrost

Reputation: 153

Check environments timezone settings

I want to be able to check against the environments timezone settings and if its not a US timezone then I will handle the datetime with a more global format. For example. I have a user in America their settings is MM-DD-YYYY now if I have another user in Canada they want to see DD-MM-YYYY but instead of just giving them different versions I would rather have some logic that grabs the timezone and compares it against something and then that determines how the datetime will be handled.

if(System.TimeZone.StandardTime = US)
  {
   objOrderEntryItemUsageReport.VarShipDate = Convert.ToDateTime(datpkrShipDate.Value).ToString("MM/DD/YYYY"); 
  }
else
  {
   objOrderEntryItemUsageReport.VarShipDate = Convert.ToDateTime(datpkrShipDate.Value).ToString("DD/MM/YYYY");

I just don't know the best way to check the environments timezone settings and even how to compare it to see if its a US timezone?

Would I need to create a dictionary with the American timezones in it and then do a while loop through that dictionary to see if the current timezone matches and if not then handle it like an international user?

Upvotes: 0

Views: 97

Answers (1)

Jon Skeet
Jon Skeet

Reputation: 1504182

The user's time zone and the user's culture are entirely separate matters.

It's not clear where this code is running, but basically you want to use the appropriate CultureInfo, and then you can use DateTime.TryParse specifying the culture. You can use TryParseExact specifying a standard format of d for "short date format". (Likewise for calls to ToString... just pass in the culture and a format of d.)

Alternatively - and preferably - use a DateTimePicker so you don't need to parse the value at all. (Given your names, it's possible that you're already using a DateTimePicker, so it's unclear why you're calling Convert.ToDateTime - the Value property is already of type DateTime.

Then, don't convert it to a string later either - your VarShipDate property shouldn't be a string property, it should be a DateTime property. That's what you're trying to represent, after all. Avoid string conversions as far as you possibly can. They are error-prone, culturally sensitive, and basically full of potential fail.

Additionally, I would strongly advise against using System.TimeZone - use System.TimeZoneInfo, which is effectively the replacement for TimeZone.

Upvotes: 3

Related Questions