[Zope3-dev] Can we remove ZopeLegacy for now?

[Guido van Rossum]

> Here is a copy of what I posted to the wiki. Hope it helps.
> 
>  Timezone use case:
> 
>  A shared calendar web application. Data is stored in ZODB. We have Event
> objects. An event is scheduled in advance of its occurence and has a
> datetime attribute representing the start of the event. A single event (a
> telephone conference call, for example) can be associated with more than one
> person. Each person may be in a different timezone. As each person views the
> list of events on their schedules, they will see each event (the telephone
> conference call in which they will participate, for example) datetime value
> represented in their local timezone. They can also see the local time for
> each of the other people who will participate in the same event.
> 
>  An event scheduling application. Person A in timezone A is setting
> appointments for Person B in timezone B. Person A sets appointments with
> people in all timezones in the world. Person B tells Person A when they will
> be available for appointments. Person B represents these start/stop
> datetimes in their own timezone. When Person A calls people around the
> world, Person A must be able to see Person B's availability reflected in the
> timezone of the person they are calling, since the person being called
> expects to be able to set an appointment from the point of view of their own
> timezone. All appointments are recorded in a shared calendar as described
> above.
> 
>  I hope this helps. This is part of a real application that I am developing
> using ZODB. I have not gotten to the calendar part yet, but I will in a
> month or two, which is why I have a real interest in the end result of the
> new datetime type.

Very good use case.  Thanks you!

I'd like to add a use case for date/time arithmetic based on this.

Associated with an event can be one or moe alarms.  Each person can
set their own alarms.  There can also be shared alarms.  You specify
an alarm as N {days|hours|minutes} in advance.  When specifying days,
this should do the sensible thing across DST jumps, i.e. an alarm for
a noontime meeting one day before the meeting should go off at
noontime (local time for the person who set alarm) the day before,
even if 23 or 25 hours pass between the alarm and the scheduled event.

And another use case from the same application: event scheduling often
requires calculating things like the 3rd Wednesday or the last Friday
of each month.  Especially the latter is interesting.

--Guido van Rossum (home page: http://www.python.org/~guido/)