Andi,
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?
Thanks,
...Bryan
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 [1] 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
view.tzinfo.default.
When view.tzinfo.default is changed, so is what view.tzinfo.floating
wraps.
- Almost (except some unit tests) everywhere ICUtzinfo was used
statically,
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
arguments.
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
events
actually float instead of being stuck like boat anchors.
Currently, this callback is set in Utility.py and just logs the
timezone
change.
- When chandler is started, the UI view's default timezone is set to
the
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.
Andi..
[1] svn+ssh://svn.osafoundation.org/svn/chandler/branches/chandler-tz
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
Open Source Applications Foundation "chandler-dev" mailing list
http://lists.osafoundation.org/mailman/listinfo/chandler-dev
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
Open Source Applications Foundation "chandler-dev" mailing list
http://lists.osafoundation.org/mailman/listinfo/chandler-dev
