[Chandler-dev] About timezone changes and usage of ICUtzinfo

[Bryan Stearns]

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