[Dev] TimeZone support and PyICU upgraded to 0.2-27-1
jeffrey at skyhouseconsulting.com
Tue Jun 21 12:45:34 PDT 2005
Hi Grant et al,
> There was some discussion of this the other day on IRC, but it wasn't
> clear to me what we'd decided about using a Type or a Kind to store
> timezones in the repository.
> 1. Andi's implementation has a TimeZone type, that serializes itself by
> writing its ICU timezone ID out to the repository.
> 2. Jeffrey H. mentioned wanting to do a timezone Kind for iCalendar
> #1's downside is that more general timezones (in particular, the ones
> specified by an iCalendar VTIMEZONE) can't be represented. Presumably,
> the scheme could be extended (by subclassing PyICU's TimeZone object,
> and figuring out how to serialize it).
> However, that seems somewhat complex to me, so maybe #2 is better. We'd
> have to do some work to match VTIMEZONEs to ICU's timezones (since that
> would help with picking up correct translations, and correct
> date/time/calendar calculations).
To be clear, here's the heuristic I propose that Chandler use for
working with Timezones:
A) Chandler offer only PyICU's timezones in UI when selecting a timezone.
B) When iCalendar files are imported/subscribed to, any VTIMEZONEs will
be compared to PyICU timezones with similar offsets. If a VTIMEZONE's
offset and daylight savings time dates are a perfect subset of a PyICU
timezone, the PyICU timezone will be persisted. Note that
America/Los_Angeles is equivalent to US/Pacific, so a half hearted
attempt will be made to choose an alias similar whose name matches the
VTIMEZONE's. This would at least work smoothly for Chandler -> Chandler
C) If a VTIMEZONE doesn't match a known PyICU timezone, it would be
persisted as an item of a different Kind than PyICU timezones,
ICalendarTimezoneKind (perhaps it should be a Type, not a Kind?). This
would be a rare occurrence, happening only when political regions
changed their daylight savings time regime to something completely new,
but it does happen. Chandler code working with timezones would need to
be able to accept either variety of timezone.
More information about the Dev