Reputation: 153
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
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