Re: 0.7.26 now available

> Isn't that non-obvious and confusing?
> 
> Why not just have a two "end" fields.  One for end of event, and one
> for end of repeating.

Joe has tried really hard to be backwards compatible with the prior code
which was arbitrary and stupid as it was exactly the LG format, fields and
semantics.  Of course it is difficult to know what exactly was arbitrary :-)

Anyway the LG phones didn't let you send end dates using the phone UI
for repeats, but did store 4095 as the end year.  Altering the underlying
data did work - you just couldn't see or alter it in the UI.  It also used
the one start date/time and one end date/time with the above semantics for
repeating events.

The really important prinicples for what the schema should be are:

 - No duplication of information.  No two fields should store the 
   same or interdependent information in such a way that it is
   possible for them to be inconsistent

 - Fields should end up being None when not set rather than a
   specific value.  This is so that we can always tell whether a
   value is intentional and set or unset.
 
 - Be very close to the standards (eg vCal) for the fields and
   semantics

I haven't looked into the new calendar deeply enough to know what
exactly is going on, and this case certainly looks ambiguous.

Roger


-------------------------------------------------------
This SF.Net email is sponsored by: IntelliVIEW -- Interactive Reporting
Tool for open source databases. Create drag-&-drop reports. Save time
by over 75%! Publish reports on the web. Export to DOC, XLS, RTF, etc.
Download a FREE copy at http://www.intelliview.com/go/osdn_nl