Quote:
Originally Posted by Tedallen
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 :-)