[Chandler-dev] About timezone changes and usage of ICUtzinfo
stearns at osafoundation.org
Mon Jun 18 17:03:20 PDT 2007
A couple of questions about this...
- Why does each view need its own timezone? I understand that indexing
requires tying the floating timezone to a particular timezone, and that
reindexing is necessary when the particular timezone changes, but it
seems simpler to force the change to happen in lockstep (one view
reindexes; the rest wait during indexing, then refresh) than to allow
every view to have its own timezone.... partly because I don't
understand how the reindexing can work:
- You say that when one view's timezone changes, reindexing occurs.
Indexes are persisted, though - doesn't that mean that views will fight
over this? Or will we end up with an index per timezone?
Andi Vajda wrote:
> Because we index floating events, changing the system timezone or the
> ICUtzinfo.default timezone needs to be done with care. Namely, it
> can't be done globally as it is now in chandler as that causes indexes
> with floating events to get out of order. Bug 9508 is just the tip of
> the iceberg.
> Instead, the default timezone needs to be set per view and persisted.
> All direct uses of ICUtzinfo's static methods and attributes need to
> be re-routed though a view.
> Since this change is quite big, I created a branch of the chandler
> tree (sharing external and interal with trunk) at  that implements
> the following changes:
> - All static accesses to ICUtzinfo such as ICUtzinfo.default,
> ICUtzinfo.floating, ICUtzinfo.getInstance(), etc.. are re-routed
> via a
> new view feature, called view.tzinfo, that has the same APIs as
> ICUtzinfo's static APIs.
> - A view now persists its default timezone.
> - view.tzinfo caches UTC, GMT, and floating as view.tzinfo.UTC and
> view.tzinfo.GMT. The floating timezone no-longer delegates all its
> operations to ICUtzinfo.default but instead wraps
> When view.tzinfo.default is changed, so is what view.tzinfo.floating
> - Almost (except some unit tests) everywhere ICUtzinfo was used
> I changed it to an equivalent view.tzinfo call.
> - A lot of code still had to change to accomodate having a view
> nearby to
> enable such view-based timezone access. At this time, all unit
> tests pass
> on the branch. I have yet to try functional tests.
> - When view's timezone is changed in one of the following ways
> . assigning view.tzinfo.default
> . calling view.tzinfo.setDefault
> . refreshing to a version with a new timezone
> . changing the system timezone and restarting chandler
> a callback is invoked with the view and the new timezone as
> This callback, settable via the 'ontzchange' repository and view
> init keywords needs to be implemented by the application so that it
> invokes the relevant reindexing code to make sure that floating
> actually float instead of being stuck like boat anchors.
> Currently, this callback is set in Utility.py and just logs the
> - When chandler is started, the UI view's default timezone is set to
> system timezone. This can be overriden with a new --tz command
> line arg
> whose purpose is testing and debugging.
> Please, take some time to review this branch, especially once I have
> functional tests passing. All unit tests pass already.
> I hope to have functional tests passing either tonight or Wednesday.
> If no one objects to these changes, I intend to merge this branch into
> the trunk on Thursday or Friday.
>  svn+ssh://svn.osafoundation.org/svn/chandler/branches/chandler-tz
> _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
> Open Source Applications Foundation "chandler-dev" mailing list
More information about the chandler-dev