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 > import. > > #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 sharing. 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. Sincerely, Jeffrey _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ Open Source Applications Foundation "Dev" mailing list http://lists.osafoundation.org/mailman/listinfo/dev
