Take the 2-minute tour ×
User Experience Stack Exchange is a question and answer site for user experience researchers and experts. It's 100% free, no registration required.

I am currently working on a calendaring application that needs to deal with a list of tasks that the user can create.

In all calendaring applications I have used (outlook, thunderbird, google calendar), there isn't a way to set a time for tasks. One can only set a due date for the task.

For example, the task list might look like:

  • 24/12/2011 - Get Christmas presents ready.
  • 5/1/2012 - Finish important assignment

Let's assume that the user is currently in the Australia\Sydney timezone. If the user were to move to a different timezone, say America\New_York, is it useful to try and attempt to localize these dates into the local dates at America\New_York?

The problem with doing the above is that 00:00 AM 12/24/2011 to 23:59 PM 12/24/2011 in Sydney corresponds to 08:00 23/12/2011 to 07:59 24/12/2011 in New York.

Now, instead of having a task due on 1 day, we have it spanning through 2 days. This is obviously very confusing for users, however I do not want users to miss deadlines for tasks because they are in a different timezone, but the due date was set in another timezone.

What's the best way for dealing with something like this?

share|improve this question
add comment

4 Answers

up vote 1 down vote accepted

You should leave it to the "system" to keep track of the timezones (and daylight saving time for that matter). Your app should just check

if (System.TodayDate = Task.DueDate) then Task.Highlight('Due today!').

I don't think it will be a problem for the user, because the day he/she travels "with the sun", the day will in fact be several hours longer. When he/she arrives at SFO airport, he will still have some more hours to to go before deadline.

I would strongly recommend that he finishes the tasks before he arrives as SFO. There are better things to do in San Francisco than to complete some tasks on a task list ;-D

share|improve this answer
So you are saying that if the task was set to be due on the 24th of December in Sydney, Australia, the user should see the same due date (24th of December) regardless of where he is? –  F21 Nov 15 '11 at 11:49
@phpdev, Yes... –  Jørn E. Angeltveit Nov 15 '11 at 11:52
@phpdev, but I must add that this depends on the main purpose of the app. If it is supposed to be a task list for individuals, then the context of the individual user is the way to go. If, however, it is supposed to be a collaboration tool where users from different timezones are looking at the same task simultaneously. Then you should use a common concept of time. For instance UTC (just like UX.SE uses - hover over a timestamps, and you'll see the Zulu-notation that indicates the UTC-time). To establish an unambiguous "deadline", you could use a countdown, like this bit.ly/bETz3p –  Jørn E. Angeltveit Nov 15 '11 at 12:05
add comment

A few thoughts:

You should be storing your dates in UTC on the server no matter what. That way you get the timezone shift for free using javascript to do the conversion on the user's system.

The second thing is that it depends on how you calculate the due date. Are you using a duration or a fixed date. Let's say you are in Australia and your user is in New York. If you assign them a task that should take two days, is that day relative. Does that task need to be complete at a specific time or are you saying that you have 16 hours to work on it?

lastly, it sounds like tasks you have are time independant. Meaning that your due date is a day and has no time component. In this case, you don't want to do a timezone conversion.

share|improve this answer
add comment

You would show tasks as events. In 5 days view users should see in what time start and end tasks.

share|improve this answer
add comment

Time to switch over to UTC?

Sooner or later, we are going to face many more such issues without a standard.

share|improve this answer
add comment

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.

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