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.
That's right, no decision was made. I implemented the type because of a
consistency issue. It seemed that being able to store a datetime/time with a
time zone but not a time zone by itself seemed inconsistent.
2. Jeffrey H. mentioned wanting to do a timezone Kind for iCalendar import.
There is nothing stopping someone from implementing such a TimeZone kind.
The issues to cover are:
- how can these TimeZone items then be used with a python datetime/time ?
- if they are supported with datetime/time objects, how do they persist
along with these values ?
Currently, the repository only supports ICU time zones because it punts on
serializing a time zone by value altogether, it only saves the ICU's time zone
ID (of which there are 577 possibilities) since ICU already has a database of
serialized time zones.
#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).
My suggestion here would be to map the iCalendar VTIMEZONE to one of the 577
ones supported by ICU. If someone came up with a 578th time zone, adding it to
the ICU db is probably easy enough.
Andi..
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
Open Source Applications Foundation "Dev" mailing list
http://lists.osafoundation.org/mailman/listinfo/dev
