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

[Sly Gryphon <sgryphon at computer.org>]

vcarddav-request at ietf.org wrote:
> From: Marc Blanchet <marc.blanchet at viagenie.ca>
> 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