Hooray for all persisted datetimes in Chandler getting a tzinfo class!
Jeffrey
Grant Baillie wrote:
> Hi, all
>
> Here's a summary of various discussions on dealing with time zones
> (especially "floating") in 0.7. In the spirit of PyCon, there is actual
> working Python code in this email, which will hopefully make things
> clearer. In the spirit of being backward, I'm starting out with the
> proposals of how to use timezones, and ending with the motivation behind
> doing things this way).
>
> FWIW, the PyICU-level work has already been done by Andi, and I'm
> sitting on a pile of changes that implements the rest in Chandler, but
> it seemed like a good idea to send out the proposed plan of action to
> dev@ beforehand. Let me know if you have
> comments/recommendations/disagreements.
>
> Guidelines
> ----------
>
> 1. Don't store naive datetimes/times (datetimes or times with a tzinfo
> of None) in the repository. You can still use naive datetimes in your
> code, so long as you don't try to persist them.
>
> [Aside: At some point, we should make the repository reject
> datetime/time values with a tzinfo of None, similar to other repository
> type checking].
>
> 2. The default ICU tzinfo can now be accessed via an attribute rather
> than a classmethod call:
>
>>>> import datetime, PyICU
>>>> PyICU.ICUtzinfo.default
> <ICUtzinfo: US/Pacific>
>
> (This used to be PyICUtzinfo.getDefault(), which still works for now).
>
> 3. If you want to create a "floating" datetime/time (i.e. one that in
> 0.6 would have had a tzinfo of None), set its tzinfo to the new PyICU
> object PyICU.ICUtzinfo.floating, e.g.
>
>
>>>> dt=datetime.datetime(2006, 3, 2, 16, 30,
> tzinfo=PyICU.ICUtzinfo.floating)
>>>> dt
> datetime.datetime(2006, 3, 2, 16, 30, tzinfo=<FloatingTZ: US/Pacific>)
>
> This tzinfo object has the property that it will always perform
> calculations using the default ICU tzinfo (even if that gets changed):
>
>>>> PyICU.ICUtzinfo.default =
> PyICU.ICUtzinfo.getInstance("Africa/Johannesburg")
>>>> dt
> datetime.datetime(2006, 3, 2, 16, 30, tzinfo=<FloatingTZ:
> Africa/Johannesburg>)
>
> 4. In the not too distant future, we will want to enable having the
> user's default timezone be "floating" (i.e. have a Palm-like
> timezone-free mode): for details, see the following (longish) thread on
> the design list:
>
> <http://lists.osafoundation.org/pipermail/design/2006-January/003758.html>
>
> Note that "the user's default timezone" here means the timezone that's
> used to create new events. For the moment, you get at that (persisted)
> value via the TimeZoneInfo class inside osaf.pim.calendar.TimeZone:
>
>>>> from osaf.pim.calendar.TimeZone import TimeZoneInfo
>>>> from application.schema import _get_nrv
>>>> TimeZoneInfo.get(_get_nrv()) # _get_nrv is the null repository view
> <TimeZoneInfo (new): defaultInfo fce1fe34-aa35-11da-88f4-000d9359ec2c>
>>>> _.default
> <ICUtzinfo: Africa/Johannesburg>
>
>
> Motivation
> ----------
>
> As you may remember, when implementing timezone support in 0.6, there
> was a serious issue with the python datetime API: datetimes/times with a
> tzinfo of None (a.k.a. "naive" datetimes) can't raise a TypeError when
> compared with their non-naive counterparts. Here, comparison means use
> of operators like ==, <, <=, etc, as well as built-in python functions
> like cmp, max, list.sort, etc.
>
> Since we wanted to have events with no timezone (a.k.a. "floating"
> events), the somewhat kludgy strategy I took in implementing timezone
> support was to define a function (the beautiful API
> osaf.calendar.DateTimeUtil.datetimeOp) that would fix up datetimes
> before comparison, if necessary. After that, I trolled though chandler
> code for datetime comparisons that might raise, and replaced the
> offending expressions with calls to datetimeOp().
>
> This strategy is now exposing its clunky roots: For example, sorting
> columns in the summary table means that we would have to define a
> special sort function that called datetimeOp if the attribute being
> sorted on was datetime-valued. In the new scheme of things, "floating"
> datetimes have a non-None tzinfo, so we no longer get a TypeErrro during
> comparisons, and everything is hunky dory. In this case, it seems better
> to lay down rules (to use an authoritarian term) that contrain your
> data, rather than try to erect a creaky scaffolding around an
> undesirable behaviour of Python datetime/time.
>
> --Grant
>
> _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
>
> Open Source Applications Foundation "Dev" mailing list
> http://lists.osafoundation.org/mailman/listinfo/dev
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
Open Source Applications Foundation "Dev" mailing list
http://lists.osafoundation.org/mailman/listinfo/dev
