7

I am building an application on windows forms C# that will run in real time 24 hours a day 365 days a year. This application tracks the time that components are out of storage.

I am running into a problem with daylight savings time as when it hits, it will alter how long the components are out, which i need to deal with.

Im wondering if there is a built in function in .NET that handles this or if others have had this issue and know a solution?

Any help is appreciated.

7
  • 9
    This is the reason that UTC was established. (timeanddate.com/time/aboututc.html) In general it is best to store and compare dates in UTC, and if necessary display in the local time zone. Oct 3, 2019 at 12:45
  • 1
    For C# and date handling, the smart money is on using nodatime.
    – David Arno
    Oct 3, 2019 at 13:12
  • 3
    @BerinLoritsch: UTC still has leap seconds, though. If you need a monotonous, linear timescale without "jumps", TAI may be a better choice. Oct 3, 2019 at 13:27
  • So i use UTC and perodically check it, readjusting it when neccecary? Oct 3, 2019 at 13:33
  • 1
    Nevermind just found UTC never changes. Thanks for the help! First stack question succesfully answered thanks guys! Oct 3, 2019 at 13:41

2 Answers 2

3

You have basically two choices: If your data is all local, you can record the time in your local time zone without DST, and optionally a flag that DST is used. So when clicks jump forward by an hour, yours doesn’t. If an item is removed from storage 10:30 am today and put back 11:30 tomorrow with DST, the times recorded are exactly 34 hours apart. Your code for displaying data needs adapting.

Better because more future proof is storing the date in UTC or GMT, which both progress by one hour every hour. Optionally record the time zone when the data was recorded, so you know what time was on the user’s watch when he recorded it.

(Note: GMT has no DST. The UK switches to BST in the summer. In GMT each day is exactly 86,400 seconds, but the length of a second varies slightly).

11
  • " UTC or GMT, which both progress by one hour every hour." Minor nit: leap seconds It doesn't generally matter to most systems but it can create challenges.
    – JimmyJames
    May 7, 2021 at 16:08
  • @JimmyJames: Currently all my work is done on a system that claims to use UTC but is blissfully unaware of leap seconds. Or hides them from developers. It may not be the only one. “Seconds since epoch” at an exact hour is always a multiple of 3,600.
    – gnasher729
    May 7, 2021 at 17:43
  • That wikipedia page links to a rabbit hole about universal time. While I understand the reason for wanting to adjust the time to account for the earth's rotation, it seems like it would be a lot simpler to have a time that is completely agnostic to that, and then layer UTC on top of it. Are you aware of such as system?
    – JimmyJames
    May 7, 2021 at 18:05
  • 1
    @JimmyJames, agreed! Esoteric enough that I didn't remember the acronym! More sensibly, local time would have been adjusted so as to be a fixed offset from TAI. It's hard to imagine how a 37 second deviation from astronomical phenomena, could have been important to any civil purpose, or that any problem is made simpler by the insertion of ad-hoc leap seconds as in UTC.
    – Steve
    May 7, 2021 at 19:06
  • 1
    @Steve It just seems archaic to me. The development of calendars is rooted in agriculture and knowing when to plant. It as if the momentum of that has led to an obsession with solar time. I think this hasn't been an issue for a while because seconds have been added. It when they are subtracted that I think it starts getting interesting. Mostly that happens after big earthquakes, I think.
    – JimmyJames
    May 7, 2021 at 20:52
2

There are two reasons that I store time as UTC.

First, is that with global users of some of the applications I work on, local time varies per user, so local time for a user that entered the data may not be local time for a user viewing the data later.

Second, timezones change. They are subject to the whims of governments. What is UTC +5 today could be UTC +6 tomorrow just because some government says so, which would then make the local time + offset different than what was stored. You can always figure out the correct local time, but I just view it as more work than just converting UTC to local.

Those are the best reasons that I am aware of for using UTC, but I am sure there are others I haven't thought of.

Microsoft document can be found here.

3
  • 1
    There are conflicting opinions on this, primarily because "figuring out the correct local time" for a past time, can actually be more complicated than one might first suspect, especially if you aren't storing the local time, location, and/or the local timezone alongside the UTC value. And although UTC values improve the comparability of times within the domain of the application, consistency with local civil time can still be more important.
    – Steve
    Mar 27, 2021 at 18:05
  • I’ve seen bugs reported against MacOS when people converted hundred year old dates between utc and local time and got unexpected results. And usually the answer is “conversion is correct, country X used strange local time until 1925”, for example.
    – gnasher729
    Apr 26, 2021 at 6:31
  • For conversion of historic dates you need not the time zone today, but the time zone when and where the event happened.
    – gnasher729
    May 7, 2021 at 13:48

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.