Timezone change impacted due dates.

[robfrommars]

Here's a weird one. Flew from Mpls to Las Vegas. Opened up OmniFocus on my iPad, and all my due dates moved up by one day. Things normally due on Sat were now due on Friday. Same on my iPhone. I shut off my automatic time zone setting on my iPad, and set it back to Central time. Problem solved. Anybody else had this issue?

[macula]

I can report to have had exactly the same problem with OmniFocus on the Mac. I do not have an iPad, but this is an issue that apparently plagues OF on both platforms. I am a frequent traveller and hope it will be addressed soon.

[curt.clifton]

The dates in OF are stored in GMT, so a task scheduled to start at 12:00 am Friday in New York would show up as starting at 11 pm Thursday in Minneapolis. With all due respect to Einstein, those are the same times. There are a couple of problems here. On the one hand, OF manages tasks not appointments, so when a task starts on Friday, I want it to start on Friday, regardless of what time zone I'm in. On the other hand, if my MacBook is on my desk in Indiana and my iPad and I are at my parent's house in Iowa, I still want all the synchronized tasks to be consistent (e.g., the same tasks are available).

I find the current behavior somewhat annoying, but don't see how to change it without screwing up syncing.

[Kylot]

The Workaround I use on the iPad is to leave the the timezone setting the same no matter where I am. Go Settings --> General --> Date & Time and manually set the date and time to your present timezone. This leaves all the O.F. item due dates as you made them

[Brian]

As someone who spends several chunks of the year eight time zones away from where he spends the rest of the year, I'd like to see this get tweaked, too.

That said, the majority of our customers spend the majority of their time in a single time zone. All other things being equal, we try to devote our development time to the most frequently requested items; that means the improvements help as many customers as possible.

In other words, please send email to the support ninjas (omnifocus@omnigroup.com) and help this feature request move up that list. :-)

[macula]

The dates in OF are stored in GMT, so a task scheduled to start at 12:00 am Friday in New York would show up as starting at 11 pm Thursday in Minneapolis. With all due respect to Einstein, those are the same times. There are a couple of problems here. On the one hand, OF manages tasks not appointments, so when a task starts on Friday, I want it to start on Friday, regardless of what time zone I'm in. On the other hand, if my MacBook is on my desk in Indiana and my iPad and I are at my parent's house in Iowa, I still want all the synchronized tasks to be consistent (e.g., the same tasks are available).

I find the current behavior somewhat annoying, but don't see how to change it without screwing up syncing.

I thought to bump this thread as my travel schedule has become more intensive and I see my OmniFocus workflow seriously disrupted as a result of this bug (or feature, as others may call it).

At the very least, I would like to see an option allowing "floating" start and end times, in the manner of iCal ("floating" in this case means that start and end times remain the same regardless of time zone).

The potential problem that Curt brings up—namely that synching would be messed up as different tasks would be deemed "available" in different time zones—can be addressed by synching the entire OmniFocus library to both machines and determining availability "locally," so that each machine would have its own list of available tasks without any inconsistencies creeping in.

Or am I missing something?

[whpalmer4]

The potential problem that Curt brings up—namely that synching would be messed up as different tasks would be deemed "available" in different time zones—can be addressed by synching the entire OmniFocus library to both machines and determining availability "locally," so that each machine would have its own list of available tasks without any inconsistencies creeping in.


The entire library is already synced to all machines.

[macula]

The entire library is already synced to all machines.

Actually, I thought so and this is why Curt's post puzzled me somewhat.

Perhaps the venerable Applescript wizard Rob Trew could contribute a script that would adjust the start and end times (and dates, when necessary) according to the current timezone?

[RobTrew]

Perhaps ... Rob Trew could contribute

Venerable but a bit busy, and commuting less than before :-)

Not sure that enough data is stored for this at the moment - the dateModified field might need a twin field on the lines of TimeZoneWhereModified.

[Brian]

At the very least, I would like to see an option allowing "floating" start and end times, in the manner of iCal ("floating" in this case means that start and end times remain the same regardless of time zone).


Yeah, essentially we'd have to add a per action/project/group "floating" checkbox, which means modifying the database under the hood to store that setting. Once you do that, you need to ensure that everyone updates their app to the versions that know what to do with that setting, and make sure that nothing bad happens when they inevitably sync a device running an older version... It's a small feature on the surface, but under the hood it's a bigger deal for the engineers and QA.

I'll be heading over to the UK again in a few weeks, and this issue will inconvenience me during that time; I feel your pain.

If it helps, looking at the development database, this looks like the kind of thing we'll change someday; it's not a huge group, but there are a number of other folks that want this change too. At the moment, though, there are other things that customers as a whole want more. (And that metric sets aside things like "support iOS 5", which aren't on that list but we can assume would show up really fast if we didn't add them.)

If we lived in a world with infinite engineers, we wouldn't have to prioritize and could just work on everything at once; let's hope that day arrives sometime soon. ;-)

[macula]

Venerable but a bit busy, and commuting less than before :-)

Not sure that enough data is stored for this at the moment - the dateModified field might need a twin field on the lines of TimeZoneWhereModified.

I see… Then how about a crude but practicable solution: A script that would shift the start and end times (and dates, when necessary) of the entire library by a user-specified number of hours (positive or negative). This would effectively amount to a manual timezone change.

[Tedallen]

I see… Then how about a crude but practicable solution: A script that would shift the start and end times (and dates, when necessary) of the entire library by a user-specified number of hours (positive or negative). This would effectively amount to a manual timezone change.

A script would not be of any use to those of us who run on iPad and iPhone but don't own a Mac.

Those of you who enter actions on Mac only also have a fix in that you can change the default times that get entered. So you could set up so that the default start time is 2 or 3 in the morning rather than midnight. That would give you some cushion.

Those of us with iPads have start times of midnight and due times of 5 pm hard wired into the program.

One of the better solutions I have seen was a small app for Palms that popped up anytime the clock changed by more than 29 minutes. It asked you if you wanted to roll your appointments or not. It was an all or nothing action but it allowed you to manage the majority of your appointments

[whpalmer4]

Those of you who enter actions on Mac only also have a fix in that you can change the default times that get entered. So you could set up so that the default start time is 2 or 3 in the morning rather than midnight. That would give you some cushion.

Those of us with iPads have start times of midnight and due times of 5 pm hard wired into the program.

No, the Mac app only offers you the option of changing the default due time, not the start time.

Looking at a sprinkling of actions and projects with start dates in my database, most of them fall into one of two cases:


Start dates that are really a date only
Start dates that reflect the hours of availability of some resource


The date-only ones aren't really affected much at all by hopping a few time zones, as they are just me putting something aside until I'm ready to give it some attention, or it is possible to act. It isn't likely to matter a great deal if the "don't bother with this until Tuesday" project actually shows up at the equivalent of 9PM Monday in the original time zone, or even hours later than expected on Tuesday in the new time zone. It's unlikely to get done as soon as it hits the active list anyhow.

The ones that reflect the hours of availability of some resource are not likely to need adjustment if I go to a different time zone. If I need to call Joe between 9AM and 3PM on Tuesday, that's 9AM-3PM on Tuesday in Joe's time zone, not mine, so that time better not change just because I decided to take the Gulfstream for a change of scenery.

Now, I'm sure there would be some that would be advantageous to change if I went to a different time zone for a week. For the non-repeating actions to be done during that week, using a variant of Dan Byler's Defer script that took hours as an argument instead of days would do the trick to adjust the times to local time (close to what macula suggested, but I don't think you want to change everything). The sticky bit concerns repeating actions done while in a different time zone; the next repeat is going to be scheduled for the local time in the travel time zone and be wrong when you return home. Probably one would want to pull up a perspective grouping and sorting by date added to audit the various newly added actions for correct date/time (the same script could be used to correct them, of course). Those without a Mac are still out in the cold in this scheme, I'm afraid.

The best solution, of course, is to clear the decks before the trip so that nothing needs to be done with OmniFocus :-)

[macula]

Looking at a sprinkling of actions and projects with start dates in my database, most of them fall into one of two cases:


Start dates that are really a date only
Start dates that reflect the hours of availability of some resource


The date-only ones aren't really affected much at all by hopping a few time zones, as they are just me putting something aside until I'm ready to give it some attention, or it is possible to act.



Actually, it does bother me when this happens. These "available but not really so" tasks somehow make my database less crisp, precise and focused than I'm used to.



The ones that reflect the hours of availability of some resource are not likely to need adjustment if I go to a different time zone.


Curiously, perhaps, I have almost no such tasks in my database. In my usage pattern, most tasks with a start date belong to the category you mention below:


Now, I'm sure there would be some that would be advantageous to change if I went to a different time zone for a week. For the non-repeating actions to be done during that week, using a variant of Dan Byler's Defer script that took hours as an argument instead of days would do the trick to adjust the times to local time (close to what macula suggested, but I don't think you want to change everything). The sticky bit concerns repeating actions done while in a different time zone; the next repeat is going to be scheduled for the local time in the travel time zone and be wrong when you return home. [macula's emphasis]

It is not so sticky, to my mind, if one applies the reverse start date displacement to the newly generated repetitions. So if "do morning yoga" is completed in a new timezone, generating the next iteration in that new time zone, one could apply the script as one returns home and have the new iteration shifted back to the original timezone.

[whpalmer4]

It is not so sticky, to my mind, if one applies the reverse start date displacement to the newly generated repetitions. So if "do morning yoga" is completed in a new timezone, generating the next iteration in that new time zone, one could apply the script as one returns home and have the new iteration shifted back to the original timezone.
I thought I suggested doing just that? The problem is that you have to remember to do it, and the new ones might be sprinkled all over the database. With enough new actions to search through, picking out the ones needing adjustment could be tedious. I'm not sure if one could construct a query for Where in OF that would pick out just the tasks with a start time of 3 AM on any date, for example.