7

I'm currently adding an out of office like system to a website, where users will be able to mark their out of office dates and times such that they can provide another users's information to use as a backup while they are out.

The problem I have, is converting the users's local time to UTC. I've seen other posts that address this issue by supplying UTC to the user, and having the client (js) convert the time to and from local time. I do, however, have access to a propriety system I can use to convert the date server-side based on the user's time-zone preference.

My question is this: Should I use the server side conversion, which would allow a user's home local time to be supplied (say, their US time, regardless of where they are logged in), or should I use the client side conversion?

Does anyone have any experience with this? What are some of the less obvious advantages / disadvantages of each method?

cwharris
  • 17,835
  • 4
  • 44
  • 64

2 Answers2

13

Storing everything in UTC is a very good idea and I recommend that you stick to it.

There are few approaches you can use. I assume that you would have User's profiles. You may decide to give users an ability to pick the time zone they prefer and display everything using this information. As well as treat all user input appropriately (convert on server side, assuming the time zone is preferred one).

Another way to handle it, is to actually take User's time zone offset via Date.getTimeZoneOffset() and send it out to your server somehow (i.e. via hidden form field or Ajax). When you know that, showing everything in User's time would be piece of cake. In this case you might want to convert date/time on the client and send it out as UTC (or use hidden form field with time zone offset).

In both cases you handle database date conversion on server side. This is the best approach from my experience. I would like to point out, that apart from just converting time zones, you probably should think about displaying date/time in correct format (i.e. depending on AcceptLanguage header value).

Paweł Dyda
  • 18,366
  • 7
  • 57
  • 79
  • 1
    I would point out that it's also an option to allow the user to specify his/her timezone, but default to the current browser's timezone to begin with. This way if users do not supply a timezone, that will still see the correct time. Yet, it still leaves the flexibility available. However, for starters, I believe I will just be using the current browser's time offset, as you stated. :) Thanks! – cwharris Apr 15 '11 at 15:52
1

The issue comes down to whether you think that users will set the correct time in their profile and whether you think that they have a client set to the timezone that their computer is set to.

If the home time setting is an optional one in the profile (one that a large number of users will not have set properly), then you should use the client side time.

If you expect a lot of users to be accessing the system from a computer not set to their preferred timezone (say if they are accessing it from a hotel computer), then you should do the convert the time on the server.

If both of these apply to you, are are damned if you do and damned if you don't.

If neither one applies than both solutions will provide equal, satisfactory results.

No matter what you choose, it is a good idea to add a time stamp to the time when you display it to clear up any confusion.

Konstantin Tarashchanskiy
  • 2,762
  • 2
  • 31
  • 46