Faulty behavior in iGoogle after changing time zones...
(closed account) says:
When I set up RTM, I was living in Korea. For 8 months I've been using it daily with no problems. Then I moved to the US, and the behavior in certain activities has changed.
What I changed: I set up my account on Korean time (GMT+9) (but with my other account info specifying US info). When I moved back to the States, I altered my time zone to US/Mountain (GMT-7). That's all I've altered on the website. I have also verified that the same timezone changes have occurred on iGoogle, Google calendar, my computer, etc.
What is not working as it should:
1. RTM module on iGoogle: Often, when I postpone a task, I get the message that the task is postponed, but it still shows as being overdue and the due date on the task is unchanged. When I complete a task it does complete properly, though I believe (I'm not positive) I have had a daily recurring task then appear on the same day again.
2. RTM website: If I postpone a task on the website, sometimes (not always) it still shows as overdue on iGoogle. If I then postpone that task on iGoogle, it correctly updates to being due today. However, the following day the same behavior in (1) occurs.
3. Subscribed tasks in Mozilla Sunbird: The same overdue behavior occurs here as it does in iGoogle. I've simply got a read-only subscription to the iCalendar address provided by RTM, so I can't postpone tasks using Sunbird, but it should still show the same due date as the website does.
The issues basically come down to not properly postponing tasks, and showing different due dates on different sources. It looks strangely like it's simply using a date/time value for due dates stored in one time zone and then translating that time to my local time, reflecting a different day after the translation.
Any help or ideas would be appreciated!
jeff
What I changed: I set up my account on Korean time (GMT+9) (but with my other account info specifying US info). When I moved back to the States, I altered my time zone to US/Mountain (GMT-7). That's all I've altered on the website. I have also verified that the same timezone changes have occurred on iGoogle, Google calendar, my computer, etc.
What is not working as it should:
1. RTM module on iGoogle: Often, when I postpone a task, I get the message that the task is postponed, but it still shows as being overdue and the due date on the task is unchanged. When I complete a task it does complete properly, though I believe (I'm not positive) I have had a daily recurring task then appear on the same day again.
2. RTM website: If I postpone a task on the website, sometimes (not always) it still shows as overdue on iGoogle. If I then postpone that task on iGoogle, it correctly updates to being due today. However, the following day the same behavior in (1) occurs.
3. Subscribed tasks in Mozilla Sunbird: The same overdue behavior occurs here as it does in iGoogle. I've simply got a read-only subscription to the iCalendar address provided by RTM, so I can't postpone tasks using Sunbird, but it should still show the same due date as the website does.
The issues basically come down to not properly postponing tasks, and showing different due dates on different sources. It looks strangely like it's simply using a date/time value for due dates stored in one time zone and then translating that time to my local time, reflecting a different day after the translation.
Any help or ideas would be appreciated!
jeff
(closed account) says:
One more addition to (2) above: If I postpone on the RTM website, then look in iGoogle but do nothing (and verify the tasks there are still showing as due yesterday), then return to RTM, I have had tasks revert back to being due yesterday. That one really puzzles me.
(closed account) says:
I just submitted a problem report as was requested in forum topic 4979 (the first time I saw this but before I really knew what all the symptoms were).
torfason says:
Not sure if this is exactly the issue, but probably closely related. I use the GMail plugin, and I've found that RTM is a bit picky about all sources of time zone information being synchronized (manually). It got me very confused last summer, including problems with tasks not updating and postponing correctly. Now I am time zone switching again and I think I've got it right. What I've done:
- Change the Google Calendar time zone
- Change the system time zone of my computer
- Change the time zone settings in RTM
- Restart my browser(!) Logging in and out of RTM is not enough.
This may be overkill, but I will make sure to get this all done correctly to ensure that time zone issues don't reduce my productivity.
- Change the Google Calendar time zone
- Change the system time zone of my computer
- Change the time zone settings in RTM
- Restart my browser(!) Logging in and out of RTM is not enough.
This may be overkill, but I will make sure to get this all done correctly to ensure that time zone issues don't reduce my productivity.
(closed account) says:
This is not an acceptable set of actions to have to perform. I mean, really, c'mon!
I found out that in the underlying framework, tasks are saved in the timezone they are created in, and they are displayed in the timezone you have set in your options. This is useful for some people in some cases, but in my case it breaks how I use RTM.
The two cases I can think of are the way it's implemented (useful if a person has tasks that really need to alarm differently as they travel the world?) and my case, where a task due date is implied to be in the timezone I am currently in.
In my usage, I don't think of tasks as being tied to a clock, only to a calendar date. If it's tied to a clock, I use a calendar event rather than a task. If I am currently in the US and I am creating a task that's due on Monday in two weeks when I am in Australia, I want that task to show up on the right day in Australia, not the day with that same date in the US (which would be the following day in Australia)... that just feels broken.
Why not have a single checkbox somewhere so that I can choose which of these two applies? Then, when I change timezones, a simple SQL query updates the underlying records to apply the new timezone to all my tasks? This should be a simple fix, IMHO.
Does anyone else agree that this would be a desired behavior?
I found out that in the underlying framework, tasks are saved in the timezone they are created in, and they are displayed in the timezone you have set in your options. This is useful for some people in some cases, but in my case it breaks how I use RTM.
The two cases I can think of are the way it's implemented (useful if a person has tasks that really need to alarm differently as they travel the world?) and my case, where a task due date is implied to be in the timezone I am currently in.
In my usage, I don't think of tasks as being tied to a clock, only to a calendar date. If it's tied to a clock, I use a calendar event rather than a task. If I am currently in the US and I am creating a task that's due on Monday in two weeks when I am in Australia, I want that task to show up on the right day in Australia, not the day with that same date in the US (which would be the following day in Australia)... that just feels broken.
Why not have a single checkbox somewhere so that I can choose which of these two applies? Then, when I change timezones, a simple SQL query updates the underlying records to apply the new timezone to all my tasks? This should be a simple fix, IMHO.
Does anyone else agree that this would be a desired behavior?
torfason says:
I agree, but hey that's the best that's out there. Time zone suckiness seems to be an ongoing problem with web services, Google Calendar for example is a major pain (although it has become just slightly more bearable with the addition of a secondary time zone).
As an additional hint, related, but not exactly the same as the Australia issue, when I have tasks for today that were created in two different time zones, the priority ordering gets screwed up because even if the time is not displayed, the tasks created in one time zone are actually earlier in time than the tasks than the others (priority sorting happens only on concurrent tasks). Postponing tasks does not fix this, since it adds an even 24 hours to the time.
Solution: In RTM, select all tasks due today/tomorrow, hit "m" for multi-edit, "d" for due-date, and type "today" or "tomorrow" to reset all these tasks to work correctly for my new time zone.
As an additional hint, related, but not exactly the same as the Australia issue, when I have tasks for today that were created in two different time zones, the priority ordering gets screwed up because even if the time is not displayed, the tasks created in one time zone are actually earlier in time than the tasks than the others (priority sorting happens only on concurrent tasks). Postponing tasks does not fix this, since it adds an even 24 hours to the time.
Solution: In RTM, select all tasks due today/tomorrow, hit "m" for multi-edit, "d" for due-date, and type "today" or "tomorrow" to reset all these tasks to work correctly for my new time zone.