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
signature.asc
Description: OpenPGP digital signature