Daylight savings time is implemented differently (or not at all) in various political subdivisions. And if it is currently in effect, then it will happily add an hour even to a date in December.ģ. all it has is one flag to determine if daylight savings time is currently in effect. This is because daylight savings time is (probably) currently in effect on your computer, but was NOT in effect in December. If you use the built-in functions to do the conversion, it will probably be wrong. Local may mean Honolulu, or it may mean where your computer is located, or it may mean the location where your customer is located.Ģ. There are probably at least three 'locals' involved. And you want to know what local time that was.ġ. Let's say you determine that a cruise ship arrived in Honolulu on at 15:00 UTC. But if you are saving the date/time information for later reference or are computing date/times, beware! If all you are doing is getting the current time from the computer's internal clock to put a date/time on the display or a report, then all is well. I'd just like to add a general note of caution. and yes, the results for Parse() are in seconds, whereas the others are in milliseconds. ParseExact() (not converting to local) 10-15 ms ParseExact() (converting to local) 20-45 ms So I set up a console app to parse a date/time string 10000 times in a variety of ways. Singapore, Singapore time zone is Singapore Time (+08). It help you to find the time difference between several time zones and cities around the world. (Incidentally, the CultureInfo constructor was not a significant contributor to CPU usage.) Chandigarh, India to Singapore, Singapore Converter. We had profiled the app and found that the DateTime.Parse represented a significant percentage of CPU usage.
Here's what we were doing before: DateTime.Parse(dateString, new CultureInfo("en-US")) But bypassing the conversion to local time also speeds things up - by 50% or more in my tests, see below.) (I personally try to deal exclusively with UTC in the business / application / service layer(s) anyway. The AssumeUniversal flag tells the parser that the date/time is already UTC the combination of AssumeUniversal and AdjustToUniversal tells it not to convert the result to "local" time, which it will try to do by default.
Or, even better, DateTime.TryParseExact(.) If the DateTime is coming from a Web service or some other source with a known format, you might want to consider something like DateTime.ParseExact(dateString,ĭateTimeStyles.AssumeUniversal | DateTimeStyles.AdjustToUniversal) I know this is an older question, but I ran into a similar situation, and I wanted to share what I had found for future searchers, possibly including myself :).ĭateTime.Parse() can be tricky - see here for example.
0 kommentar(er)
