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?

4 Answers 4


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

  • 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
    Commented Nov 15, 2011 at 11:49
  • @phpdev, Yes... Commented Nov 15, 2011 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 Commented Nov 15, 2011 at 12:05

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.


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


Time to switch over to UTC?

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

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.