6

I realize this is a commonly asked question but I couldn't find any posts that point out the disadvantages of using/storing offset for user's time zone. Is this not a better and more efficient way?

Long drop down lists of time zones are not user friendly and most of such lists don't have all the cities anyway. They also require user to specify their time zone. I feel it may be much better to simply detect it. In my case, my app is an ASP.NET Core app with Reach front end and it's pretty easy to capture user's time zone offset via JavaScript.

Any reason why storing the offset of user's timezone is NOT a good idea?

Sam
  • 26,817
  • 58
  • 206
  • 383
  • 2
    Timezone and offset [are not the same thing](https://stackoverflow.com/a/36636543). The same offset can be used by more than 1 timezone, and the same timezone can have more than 1 offset during history, due to Daylight Saving Time (or simply because they [decided to move to another offset](http://www.dailymail.co.uk/news/article-2080211/Samoa-calendar-change-Samoans-lose-24-hours-island-moves-international-dateline.html)). As it's a N-to-N relationship, storing just the offset will give you a hint (a list of possible zones), but not the exact zone. –  Oct 20 '17 at 18:11
  • Fair point. I think the ultimate answer depends on one’s needs. In my case, I simply want to display all date time values in user’s current time zone so that they’re meaningful to the user. This includes those times when the user is away from his/her home time zone but still using my app. I feel detecting the offset change and automatically displaying all date/time values in user’s current time zone is pretty user friendly. It may be a good idea to display a notification upon detecting a change though. – Sam Oct 20 '17 at 18:16
  • In this case, you could store all in UTC, and convert to the user's timezone when displaying –  Oct 20 '17 at 18:24
  • Exactly. Currently I store all date/time values in UTC and store user’s time zone too. But more and more I feel, I have no use for user’s time zone. All I need is the offset for my conversion. – Sam Oct 20 '17 at 18:27
  • 2
    Actually, a timezone is a set of all offsets that a region had, has and will have during history (including DST changes), so only with the timezone you can get the correct offset for each UTC instant. –  Oct 20 '17 at 18:30

1 Answers1

9

Any reason why storing the offset of user's timezone is NOT a good idea?

Yes. Many. A time zone and an offset are not the same thing. A time zone represents a geographical area in which local time is aligned. A time zone may undergo several different changes in its offset from UTC. Some of which are regular (like daylight saving time), and some of which are irregular (like when a government changes its standard time or dst rules).

... In my case, I simply want to display all date time values in user’s current time zone so that they’re meaningful to the user.

Ok, so let's say you check the user's current time zone offset and it is UTC-7. So you apply that to some dates and times in your application and done - so you think. Except that you didn't take into account that the user is in California, and one of your dates is in December when the offset should be UTC-8.

So you try to correct for that, and work out the rules of "when I see -7, it might be -8 sometimes". Except now you have a user come along who is in Colorado, where it is -7 during the winter and -6 during the summer. Or another user from Arizona, where most of the state is in -7 for the whole year. How do you know which set of rules to follow? Without referencing an actual time zone, it cannot be done.

This gets even more complex worldwide. For example, the number of variations for UTC+2 is just crazy. Even for countries that switch between UTC+2 and UTC+3 - they don't all switch on the same dates or at the same time of day!

See also: The Problem with Time & Timezones - Computerphile (YouTube) and the StackOverflow timezone tag wiki.

Matt Johnson-Pint
  • 230,703
  • 74
  • 448
  • 575
  • Matt, thank you for the detailed response. I think the key to a user friendly app is to constantly check user’s time zone offset and display date/time values with the current offset. Clearly all date/time values must be stored in UTC in the database. – Sam Oct 21 '17 at 18:38
  • Say the user’s base is Denver but traveled to LA. When his laptop connects to the Internet, chances are it will update the time zone and my web app will detect a new offset value and display date/time values in the user’s current time zone. – Sam Oct 21 '17 at 18:42
  • 1
    Sure, but that offset only applies to "now". It does not necessarily apply to yesterday or tomorrow or any other arbitrary point in time. – Matt Johnson-Pint Oct 21 '17 at 19:38
  • I definitely see your point and it’s valid. This is where the app must make its own decisions. Say our Denver based user had a meeting at 2PM MT in July. He then moves to Seattle permanently and decides to check his calendar for past events that took place in July. Should the calendar show the start time of the event at 2 PM because when it happened it was 2PM in Denver or show it as 1PM because our user is now in PT. I would argue that all times past, present and future should always be displayed in user current time. That means always checking user’s current offset. – Sam Oct 21 '17 at 19:46