[chmars]

On my iPhone, plus one day equals 24 hours, i.e., my task gets postponed by exactly 24 hours. On my Mac, plus one day (+1t in German) postpones my task to the default due time.

Example:

Task 'Get up early' at 5 am tomorrow.

iPhone: Plus one day =5 am on the day after tomorrow.
Mac: Plus one day = 6 pm on the day after tomorrow (since 6 pm is my default due time).

Bug or feature?

[Brian]

Either behavior could be argued as a feature; the discrepancy between products (and confusion that causes once noticed) is probably a bug. :-)

Assuming we chose one behavior or the other, which would folks prefer? I'll file any feedback folks care to leave. Not sure when/what we'll do about this, but we'd prefer to have as much info as possible to inform that decision when it happens.

Thanks, all!

[CatOne]

Originally Posted by Brian

Either behavior could be argued as a feature; the discrepancy between products (and confusion that causes once noticed) is probably a bug. :-)

Assuming we chose one behavior or the other, which would folks prefer? I'll file any feedback folks care to leave. Not sure when/what we'll do about this, but we'd prefer to have as much info as possible to inform that decision when it happens.

Thanks, all!

An interesting question, as if I did "+1d" I might want it to go to the default time the next day. As I don't know whether it should be relative.

What about doing something like having +1d be different than +24h? Or are they different enough already?

I don't frankly use the hourly granularity all that often.

[chmars]

Originally Posted by CatOne

What about doing something like having +1d be different than +24h? Or are they different enough already?

+1d raises my expectation that only the day gets changed but not the time, i.e., I consider +24 the same as +1d.

[chmars]

Originally Posted by Brian

Either behavior could be argued as a feature; the discrepancy between products (and confusion that causes once noticed) is probably a bug. :-)

Assuming we chose one behavior or the other, which would folks prefer? I'll file any feedback folks care to leave. Not sure when/what we'll do about this, but we'd prefer to have as much info as possible to inform that decision when it happens.

In any case, I hope for a consistent solution, there are enough other consistency issues … ;)

BTW, a related issue is the following: If OmniFocus does not recognize your input into the due field, the due date simply gets removed. I have missed our more than one task that way.

FWIW the SetDates script interprets a simple "1" or "+1" as a due date deferral of exactly 24h.

[Lizard]

I think there's some confusion here. Here's what I observe:

If there is no date filled in, the iPhone [+1 day] button sets a due date of tomorrow at the default due time. Typing "+1d" on the Mac also sets a due date of tomorrow at the default due time.

If there is a date set on the iPhone, [+1 day] adds 24 hours to the date. There isn't any such button on the Mac. Perhaps there should be?

The Mac does allow for "1d 5am" and similar, for setting a due date & time without having to mentally calculate the exact date.

[whpalmer4]

Expanding on Lizard's post a bit:

The Mac has +<num>h[our]|d[ay]|w[eek]|m[onth]|y[ear] as part of the constructs it understands for date fields, but you don't get to use them in addition to whatever value is already in the field. It's the opposite for the iOS apps, where you get the +1d|w|m buttons to add to the value shown on the date/time picker wheels, but you can't enter expressions. The iOS buttons use the default times if there is nothing in the field when you press them.

If your expression only contains days (or larger) and/or dates, OF will use the default time for the field. So, as I write this at 11:10 AM on 2/15, a start date of "+1d" will get 2/16 12:00 AM and a due date of "+1d" will get 2/16 5:00 PM. However, if you have smaller units (hours) or a time included in the expression, OF will use it. "+1d3h" will get 2/16 2:10 PM for both start and due fields, as will "+27h". Similarly, "+1d 3pm" will give 2/16 3 PM for both start and due fields.

I find myself switching between the two (or using the various scripts) when editing existing dates to get the best of both worlds. Deferring something by a few days or a week is much easier with the iOS interface, but addition of those buttons to the Mac UI would close that gap. Using the scripts on the Mac allow changing multiple items simultaneously, and that overcomes the nuisance factor if there are lots of items to update. Setting up dates in the distant future is much easier on the Mac, of course.