[Design] Bug 7522: start and end time automagically changing wrong

[Bryan Stearns]

hamstar, JeffreyH, philippeB,

I took bug 7522: https://bugzilla.osafoundation.org/show_bug.cgi?id=7522 
(start and end time automagically changing wrong)

However, the end of the discussion there isn't conclusive, so I'm moving 
it back to the design list:

The story so far: Priscilla wanted to enter an event that crossed 
midnight (eg, starting at 10PM for four hours), by changing the end time 
(on what was then a 1-hour event starting at 10PM) to "2:00 AM". The 
existing date/time entry behavior confused her, since the spec (see 
http://viewcvs.osafoundation.org/docs/trunk/docs/specs/rel0_6/Detailview-0.6.htm; 
look for "Under certain circumstances") currently says that "Changing 
the end date or time such that it becomes earlier than the existing 
start date+time will change the start date+time to be the same as the 
end date+time (that is, an @time event, or a single-day anytime event if 
the event had already been an anytime event)."

The mechanisms behind these fields have certain constraints:
1. We never allow the user to enter dates that would produce an invalid 
event: the end date/time must always be after the start date/time. 
(Internally, this is because we represent events as a start date/time 
and a duration, not as separate start and end date/times - this works 
out better for e.g. recurrence & timezone handling.)
2. When automatically changing other fields on entry, do so without any 
"history": each entry operation looks at the underlying values on the 
event, and can change them, but can't tell what values they used to 
have, etc.
3. Our only current way to reject entry in a field is to quietly add a 
"?" to it (try entering "foo" in a time field to see this). In this 
situation, the underlying event's value is left unchanged.
4. Anything in the application that subsequently changes an underlying 
value causes the field to reload, even if it's invalid. The user expects 
this behavior when dragging an item in the calendar - the detail view 
fields update during dragging. In this case, though, if the user entered 
a too-early 2:00 AM in the end time, and we changed that to "2:00 AM ?" 
without changing the underlying value, and the user changed the end date 
to the next date, the end time field would reload itself automatically 
to whatever time was there before the bad 2:00 AM was entered. We could 
add more special-case code to handle that, but that snowballs.

(Changing these is doable, but could be a kettle of fish we'd prefer to 
leave closed until after Preview.)

Comments on the bug added several partial proposals:

#2: Dan says that when seeing an end time change that would be before 
the start time, we should automatically change the end date by a day. 
This is doable by itself.

#3: Mimi says that we should do what Dan suggests, if the start time is 
after 5PM. This is also doable.

#4: Jeffrey says that the opposite behavior might be useful: on a 12/16 
9PM - 12/17 1AM event, changing the end time to 11PM should change the 
end date to 12/16, even though 12/16 9PM - 12/17 11PM is valid. This is 
doable, but I think the cases where it'd be useful are less common 
(than, say, events that crossed several midnights, which'd be 
confusing); I think users would have a hard time figuring out the rules 
from this behavior.

#10: Mimi asks about several different possible alternatives.

I think the simplest thing is to do Dan's #2 proposal, or Mimi's #3 
modification of it (though I don't see why 5PM is a magic boundary). 
This would change the rule in the spec to: "Changing the end time such 
that it becomes earlier than the existing start date+time, if the start 
and end dates are the same (and maybe if the start time is >5PM), will 
increment the end date by one day. Other changes to the end time, or 
changes to the end date, will change the start date+time to be the same 
as the end date+time (that is, an @time event, or a single-day anytime 
event if the event had already been an anytime event)

Comments?
...Bryan