Hi Alec, > I think we do need a list of human-readable timezones in the current > language, and I don't think we want to be maintaining that list > ourselves.. hence it would be best if we could rely on the system for > this list. Seems like the tricky part is mapping any particular > system timezone into a language that we can understand. I mean, do > we, chandler, need to know or deal with daylight savings? Can we just > initialize python's timezone object to from the system data?
Chandler shouldn't need to know much about dst, whatever tzinfo classes we use know all about it. We might want to display 'Central Standard Time' instead of 'Central Daylight Time' when appropriate, but those strings (and the logic for when to display them) is provided by the tzinfo class. > When you say "variable cross platform behavior" what exactly do you > mean? If the tzinfo classes are grabbed from the Win32 registry, they'll also have a timezone description string that looks like '(GMT-06:00) Central Time (US & Canada)'. When providing the user with a list of timezones to choose from, this is probably the identifier we want to use (you can see this list in win32 if you double click on the clock and select the timezone tab). The particular strings chosen will be different on different platforms. This probably isn't that big a deal, but examples of quirks this would create: On windows, you couldn't easily come up with a short string like "5:00PM CST", you'd have to use "5:00PM Central Standard Time", when you start worrying about pixel level details, that could be annoying. More significantly, when iCalendar exported the timezone, we wouldn't have a ready made no-whitespace string like America/Los_Angeles to stick in the TZID parameter for datetimes, so the TZIDs we created would rarely match CalDAV server's timezone collection (see my other message for more about this). Finally, if a Windows user shared an event with a Mac user, the Mac user would import the shared event with a TZID it didn't know about, so it would either need to create a new timezone in the repository (new, in this case, only in the sense that the strings describing it were different), or we'd need to use code to check the equivalence of timezones (not terribly hard to do, I think, but I haven't tried yet :). If new timezones were created, events generated by a Windows user would be rendered on the Mac slightly differently from events generated on the Mac. None of these seem like showstopper issues, I'll admit, but they seem less than ideal to me. The alternate approach would be to ship a 50K zoneinfo database for Windows builds, so TZIDs would look very similar between win32 and other platforms. The only challenge in this would be that it isn't completely obvious how to map information about a win32 user's local timezone into an appropriate zoneinfo key. Should what win32 thinks of as '(GMT-06:00) Central Time (US & Canada)' be mapped to America/Winnipeg? America/Chicago? If the win32 tz list is static (I don't think its changed much lately), we could come up with an arbitrary mapping for this, but it might be unfortunate if win32 adds a new timezone. Sincerely, Jeffrey _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ Open Source Applications Foundation "Dev" mailing list http://lists.osafoundation.org/mailman/listinfo/dev
