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 task management application that allows users to create and assign tasks, set start and due dates and track work progress.

In my app users do not plan hours, they just set start and due dates as 10-Oct-2013 - 20-Oct-2013.

The problems happen in case when Reporter (task creator) and Assignee live in a different timezones so at the same time it may be Tuesday for Reporter but still Monday for Assignee. And vice versa.

Obviously there are two ways of dealing with dates:

  1. Use server (or account settings) timezone to define current day for all users
  2. Use each user’s local timezone to define his current day

But both ways lead to total madness. Just a look at the examples:

The madness of using common timezone for all users:

  • Say, it’s Monday morning. Assignee opens his task list. Suddenly he sees that all the tasks with deadline for today are marked as overdue! He believes he has the whole day to finish them, but they are overdue already!
  • Also Assignee can see tasks with the start date on Tuesday scheduled for today! That can happen if my timezone is UTC-9 and account’s timezone is UTC+9.
  • In other timezone combinations Assignee can see tasks with the start date equal to his today but they are scheduled for tomorrow.

The madness of using each users local time:

  • Reporter lives in UTC+9 and Assignee lives in UTC-6. If reporter creates task that should be started immediately (and sets today as start date) then Assignee gets the task scheduled for tomorrow because his local time is still yesterday.
  • Say the task start date is 10-Oct. At the same time it’s status will be already “In progress” for Reporter but “Starts tomorrow” for Assignee.
  • If Reporter build a report with Assignee’s current tasks then the app will use his local time to define today. But for the Assignee it may be already tomorrow so his current tasks are totally different.

Does this problem have a solution? I tried ideas of converting the dates to each user’s timezone to let different users see the same start date as a different value, but that does not work properly in all cases.

share|improve this question
3  
Why not just use UTC as the timestamp and do everything by that? –  JonW May 24 '13 at 10:22
    
@JonW Timestamps could be useful in case users set date+time for tasks. But in my app they set only dates. –  Alex May 24 '13 at 15:30
add comment

1 Answer 1

Always record dates and times in UTC especially when working across time zones. Display dates and times in the user's own time zone.

Even when you record everything in UTC, what does "today" mean? Usually people mean it to be somewhere between today at 0:00 and today at 23:59:59. Which immediately has implications for someone in another timezone, even with a time zone difference of a single (or even half) hour, part of that day will be on another date.

So, as you already discovered, you cannot use only the date to record start and due requirements. No matter what time you record it in, the day differs for someone in another time zone.

When I assign today as the start date, what should be recorded is "today at 0:00" in local time" translated to UTC. But much of that day will already be gone when the task is assigned. Which will be all the more so for an assignee in an "earlier" time zone. For tasks assigned a start date in the future, you can use the date plus the time when the business day of the assigner starts. For tasks assigned today as the start date, the current time should be used. (Everything translated to UTC when recorded in the database).

Your application should warn the person assigning a task to someone in a different time zone if that someone's business day is already (or almost) over. You can hardly expect someone to start something "yesterday". It would probably help if you included a timeline in your form indicating the business hours for the assigner and the assignee.

share|improve this answer
    
Recording dates in UTC with coversion to local timezones can be not as good as it seems. Say I live in UTC+7 and I make task for you with deadline = 20-june. It means June-20-2013 00:00. It is recorded to database as June-19-2013 17:00 after conversion to UTC. Say you live in UTC+6 (1 hour difference). After this date conversion you will see the task with deadline = 19-june (means 19-June-2013 23:00). In other words, all users who live earlier than task creator will see wrong dates. Anyway other your ideas are very interesting and I will try them in a couple of days. –  Alex May 24 '13 at 15:29
1  
@Alex: To summarize my post: 1) when you are working across time zones recording dates in UTC is a requirement no matter what you do. 2) when you are working across time zones you cannot rely on dates alone to specify start and end requirements, you need time as well. 3) It is not a matter of either UTC or specifying dates and times, it is a matter of UTC and specifying both dates and times for start and end requirements. –  Marjan Venema May 24 '13 at 15:39
add comment

Your Answer

 
discard

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.