The usage of ToUniversalTime() and its sibling, ToLocalTime() can be a little tricky. Var duration = end.ToUniversalTime() - start.ToUniversalTime() // converting to UTC What if the DateTime objects you already have are set to Local? In that case, you should use the ToUniversalTime() method to convert them to UTC: var start = DateTime.Now // local time Instead of using the Now property on DateTime, use UtcNow to retrieve the date time already in UTC to perform the calculations: DateTime start = DateTime.UtcNow That way, you’ll be able to unambiguously point to an instant in time. When calculating the duration of human activities, use UTC for the start and end dates. Sure, the code above is just a toy example, but what if it were a payroll application? Would you like to pay an employee the wrong amount? What to Do? If the same had happened at the end of DST, the result would’ve been just 15 minutes! Then EndMatch got back the current time, effectively adding a whole hour to the calculation. I bet you’ve correctly guessed what just happened here: when clocks were about to hit 2 AM, DST just kicked in and moved them straight to 3 AM. The calculation is performed, and the following text is shown: One hour and 15 minutes later, the EndMatch() method runs. The StartMatch() method runs at exactly 01:00 AM. Now picture this: today is March 12th, 2017, and you live in New York City. Of course, there’s also the day when the opposite happens. If you live in an area that observes DST (Daylight Saving Time), you know there’s one day in the year when all clocks must be moved forward a certain amount of time (generally one hour, but there are places that adjust by other offsets). When you use DateTime.Now, the DateTime you get represents the current date and time local to your machine (i.e., it has the Kind property set to Local). Will this code work? It depends on where and when it’s going to run. TimeSpan duration = match.EndTime - match.StartTime Ĭonsole.WriteLine("Duration of the match: ", duration) Learn More C# Datetime Mistake 1: Naively Calculating DurationsĬonsider the code below: public void StartMatch() I’ll also show what you should do to avoid them and make your code safer and easier to reason about. I’m going to show you four common mistakes C#/.NET developers make when dealing with time. The article is interesting food for thought, but I think it’d make sense to provide more actionable information. What’s the proper way of dealing with these issues?.How likely is it that I’ll get in trouble due to one of these assumptions?.The reader is likely to leave the article wondering Now even though I like the post, I have a problem with it: it lists wrong assumptions, and then it basically stops there. I hadn’t thought deeply about time and its intricacies up until that point, and I was intrigued by how a fundamental domain could be such a fertile ground for misunderstandings. Do you remember the “falsehoods programmers believe about X” meme that became popular among software blogs a few years ago? The first one was about names, but several others soon followed, covering topics such as addresses, geography, and online shopping.
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |