Subject: Re: [VCARDDAV] Timezone reference (was: vcarddav wg status and progress)

From: Sly Gryphon <[email-masked]>
Date: Fri, 19 Jun 2009 20:32:14 +1000

[email-masked] wrote:
> From: Marc Blanchet <[email-masked]>
> Subject: [VCARDDAV] vcarddav wg status and progress
>
> - vcardrev:
>  + main issue with currently no clear resolution: timezone reference.
>   
I would like to propose (as has been done before) to use the tz database
values, and I am not sure what the opposing arguments are, e.g.
  TZ:Australia/Sydney

To frame the discussion: I think the tz database is the de-facto
standard for timezones, particular on unix systems; does anyone
seriously disagree with this statement?

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:

[TZDB] Eggert, P. and A. Olson, "Sources for Time Zone and Daylight
Saving Time Data", <http://www.twinsun.com/tz/tz-link.htm>, updated
periodically.

Whilst I am happy to use the tz database, what I am worried about is
what to do when an unrecognised value can be encountered (I think this
is also really what other people are worried about). This can occur
because applications are using different versions of the data, may only
have a subset of the database (e.g. on a device with limited capacity),
or may be simply because of bad data.

My suggestion for this is to have a structured field containing the tzid
plus the offset, e.g.
TZ:Australia/Sydney;+10:00
REV:20090612T102345Z

This gives applications a way to approximate the timezone (via the
offset), including for applications that can't generate a value, i.e.
parts are optional. The offset should be defined to be consistent with
the time specified in the REV property.

Sly

---

From: Cyrus Daboo <[email-masked]>
Date: Fri, 19 Jun 2009 09:48:17 -0400

Hi Sly,

> 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.

-- 
Cyrus Daboo

---

From: Marc Blanchet <[email-masked]>
Date: Fri, 19 Jun 2009 10:28:28 -0400

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 :
> 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.
> 

-- 
=========
IPv6 book: Migrating to IPv6, Wiley. http://www.ipv6book.ca
Stun/Turn server for VoIP NAT-FW traversal: http://numb.viagenie.ca
DTN news service: http://reeves.viagenie.ca

---

From: Eliot Lear <[email-masked]>
Date: Sat, 20 Jun 2009 12:49:18 +0200

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:
>> --On June 19, 2009 8:32:14 PM +1000 Sly Gryphon<[email-masked]>
>> wrote:
>>
>>