Plan for adding All-day / any-time support

• Add Boolean "allDay" attribute to CalendarEventMixin content model. When set, indicates that the startTime's timezone and time are to be ignored (but preserved, in case the user unchecks the box).
• Add checkbox to DetailView to set/clear CalendarEventMixin.allDay
• Remainder of work is coupled to date-time editing (do we use attribute editors? have we switched to trees-of-blocks?)
• Also, there's the timezonelessness issue - see below.

Notes

(041112) Any-time vs "All-Day" (from a conversation with Mimi and Sheila):

• An "all-day" event is one that has a separate flag, causing the timezone and any time-range to be ignored and uneditable.
• An any-time event is one that has a date, but no time range filled in (or that's had the time edited out); there's no separate UI control for it. It should also be treated as not having a timezone.

As Chao points out here, ignoring the timezone is important so that your birthday doesn't happen a day early if you happen to be a few hours east of your home timezone. However, this causes a big complication for anything that wants to blindly ask items for their date "key attribute" (see here).

To deal with this, either the date attribute needs to already be converted to local time (which might hide important info from clients), or the date-part, timezone, and time-parts need to be returned separately (putting extra burden on clients); both of these would require computation when the attribute request is made (which makes it a Property, right?).

(Alternatively, we could use a date/time representation that includes the ability to specify "no time" and/or "no timezone" - that might get us around this problem. I haven't looked at the libraries that Ted or Ken were looking at.)

(041122) Do we need a combined date-time-interval type? (from a longer conversation with Donn, and a brief one with Lisa):

I hit a speedbump when I started thinking about implementing the attribute editors for date, time, and allday UI. In CPIA, the model (eg, a calendar event), the view (the attribute editor) and the controller (eg, the detail view) are all decoupled; however, the behavior of the CalendarEvent content model attributes relating to time (specifically, startTime and allDay/anyTime) are tightly coupled. So, how will a the attribute editor for startTime know the value of the calendar event's all-day flag? Donn and I discussed several possibilities:

• The first possibility we discussed: the attribute editor is given the Item to edit - it could look at its allDay attribute directly. This is bad because it breaks encapsulation; we don't want the editor to know that it's editing a CalendarEvent - that editor wouldn't be usable for editing anything except CalendarEvent items - so we discarded this idea.

• Lisa suggested changing the attribute editor model: currently, the attribute editor used to edit a particular attribute is determined by the attribute's type (and a "style" hint). Once that editor exists, it's provided with an item and the name of the attribute to be edited. Normally, the editor only uses that attribute name to get or set the value of that attribute; Lisa's suggestion would have us change the attribute editor schema to allow specification of multiple attributes. This sounded workable, but it seemed desirable to decouple the controller (the spec for the detail view tree-of-blocks, anyway) from the specific collection of attributes involved (partly because I expect the collection of date/time-related attributes to change).

• So, we looked at encapsulating allday and anytime in a new object (either a Kind or a Type) that the CalendarEvent item could use to store the time-related information. Storing it in a single object would allow the internal representation and the attribute editor(s) to change without always having to change the view definitions, which seems a plus over the multiple-specified-attributes idea. Donn talked a lot about Kind vs Type without coming to a conclusion, and also noted that the repository is pretty agnostic about the date-time object (it currently wraps mx.DateTime); this would require it be a Type, I think.

This latter approach is what we're thinking about now; it has the big plus of looking like it could satisfy the (related) timezone issues discussed above: some events are assigned a timezone (probably because the user has specified it explicitly, like a worldwide conference call) and shift around as the user changes timezones. Others are tied to whatever timezone the user happens to be in, like lunchtime, or because it's an allday or anytime event). Because the meaning of the time includes both the timezone and allday/anytime, it's meaningless to consider the raw offset from 1970 without these other values.

(It doesn't solve the separate problem of persistently sorting a list of events independent of timezone, as might be desired in an itemcollection. One possibility here is to use the itemcollection's mechanisms to specify all the entries within 24 hours (or so: fudge for DST edge cases?) of a defined range, then sort and extract more precisely using the timezone/allday/anytime info.)

-- BryanStearns - 22 Nov 2004