On 17 Jun 2015, at 17:11, Eliot Lear wrote: > Steps for improvement: The references to the timezones is by the TZID, and that is good, but I think most parties when deciding on an event pin it to a geographical location, like city/country or so in some combination. Because of this I think ultimately a reference should be in the form of a location that the tzid service should be able to resolve to the correct TZ definition (i.e. time + location gives TZ definition). > > > How do you want user-facing client behavior to change? I'm not sure I > see that. Many clients do today ask where the event takes place. One select timezone based on a city, or location. I want that location I choose in the client to stay in the calendar object. Not be translated to some TZid (and now to a TZ definition that is inserted in the object). So, yes, having TZID in the object is a BIG step forward, the most important one. The next is to for example be able to have the address of a physical event both as location for the event and as pointer into a TZ database. Once again, tzdist is The Key Thing, that I have waited for. The rest is just implementation and agreement on what you can use for lookups. Patrik
Attachment:
signature.asc
Description: OpenPGP digital signature