[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [VCARDDAV] Timezone reference



Didn't we go through this discussion in March / April aps-area list, and wasn't one clear point coming out of that discussion that UNICODE already has a stable standard, as SJ Kissane pointed out? I would be very happy to settle for either Olson or Unicode (which is based on Olson), or for a URI/URN. However, I would rather we not see Yet Another Registry of timezones. Remember, we are talking about VCARDs whose information has to change over time (in most regions I would expect that E.164 city codes change more often than timezone definitions).

eliot

On 6/19/09 4:28 PM, Marc Blanchet wrote:
to me, as individual, the issue of referencing timezones is
significantly more important in other protocols (such as calendars) than
vcard. Moreover, it is widely used in many protocols, not only in apps
area protocols. The notion of time is intrinsic to a timezone: a time
data without a timezone reference is often not sufficient.

Therefore, I think the IETF, probably through apps-area, should define
it for all to use. To me, this is to be addressed by the AD and IESG and
have a draft->RFC to define what the IETF should use for reference to
timezones.  (adding our AD explicitly in CC ... ;-)

my 2 cents...

Marc.

Cyrus Daboo a écrit :
Hi Sly,

--On June 19, 2009 8:32:14 PM +1000 Sly Gryphon<sgryphon at computer.org>
wrote:

Given it is the standard, we should simply use the values from it, and
simply refer to the tz database the same way that RFC 4833 does:
Actually not. Window's OS's do not use Olson. That is all part of the
bigger problem of lack of standardized naming for timezone data that
results in poor interoperability in the calendaring world.

One choice for vcard right now is to go with text or uri as the value
here. Text would by convention be either an Olson name or a Windows name
- clients would have to figure out what exactly that means on their own.
The uri gives us the ability to use registered standard identifiers once
we have such things. Also, with a timezone service protocol (something
that is being worked on) the text forms could be mapped to standard
identifiers or UTC offsets as needed.