You got it wrong, but corrected yourself (see the end, below)...
Mimi Yin wrote:
[snip]
Just so I understand (because I think I'm still missing something), is
this what you're describing:
1. Priss enters the following:
*Starts:* June 1, 2007 *at* 8:00PM
(note: After Priss enters "6/1/07" & "8:00 PM", the end time is "6/1/07"
"9:00 PM", because we default to 1-hour events.)
*Ends:* June 1, 2007 *at *2:00AM
2. Chandler does:
*Starts:* June 1, 2007 *at* 8:00PM
*Ends:* June 1, 2007 *at *2:00AM ?
yes.
3. Priscilla fixes the end-date:
*Starts:* June 1, 2007 *at* 8:00PM
*Ends:* June 2, 2007 *at *2:00AM ?
4. Chandler restores original end-time
*Starts:* June 1, 2007 *at* 8:00PM
*Ends:* June 3, 2007 *at *2:00AM
Nope (as you say below): the original end time (that is, the time before
Priscilla entered the 'bad' 2:00 AM) was "9:00 PM", so what Chandler
restores is "6/3/07" "9:00 PM"... my point is that Pricilla will
probably be just as confused that her "2:00 AM" went away.
That feels like the right workflow for me.
Or are you saying that it would restore the end-time that was in the
end-time field before Priss did step #1 (e.g. 9:00PM). If that's true,
I can see how it would be extra work to treat "properly formatted
date/times that are nevertheless wrong" differently from date/times
that are wrong because they are improperly formatted.
Thx, Mimi
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
Open Source Applications Foundation "Design" mailing list
http://lists.osafoundation.org/mailman/listinfo/design
