RE: ISSUE-106: Does having a timezone field make sense, should it be utfOffset or utcOffset and tz to better match vCard

I have checked other address book formats such as OMA CAB and OpenSocial...


In CAB [1], timezone is defined as follows:

"
a <time-zone> element contains the time zone information associated with the location. This element MAY have the following child elements:
1)	a <tz-label> element that contains the description of the time zone
2)	a <utc-offset> element representing the time offset from UTC
3)	a <tz-url> element pointing to the location where the detailed time zone information is stored
"

In Portable Contacts [2], the property is called utcOffset and defined as follows:

"
utcOffset: 
The offset from UTC of this Contact's current time zone, as of the time this response was returned. The value MUST conform to the offset portion of xs:dateTime, e.g. -08:00. Note that this value MAY change over time due to daylight saving time, and is thus meant to signify only the current value of the user's timezone offset.
"

[1] http://member.openmobilealliance.org/ftp/Public_documents/COM/COM-CAB/Permanent_documents/OMA-TS-CAB_XDMS-V1_0-20101019-C.zip

[2] http://portablecontacts.net/draft-spec.html

My take is that all the specs are talking about the same representation (i.e. offset from UTC and [+-][0..9][0..9]:[0..9][0..9]) which is what we say in the spec at the moment. 

The one thing we need to be clear in the spec is whether we expect this field to be set by the user or only set by the implementation?

Suresh

-----Original Message-----
From: public-device-apis-request@w3.org [mailto:public-device-apis-request@w3.org] On Behalf Of Anssi Kostiainen
Sent: Thursday, January 20, 2011 10:04 AM
To: ext Dominique Hazael-Massieux; Christopher Hunt
Cc: Device APIs and Policy Working Group WG
Subject: Re: ISSUE-106: Does having a timezone field make sense, should it be utfOffset or utcOffset and tz to better match vCard

Hi,

On 20.1.2011, at 10.46, ext Dominique Hazael-Massieux wrote:

> Le jeudi 20 janvier 2011 à 11:43 +1100, Christopher Hunt a écrit :
>> utfOffset is not good enough alone given that has a temporal quality with regards to daylight savings time. A zoneinfo reference e.g. "Australia/Sydney" is much more meaningful as rules can be associated with this type of identifier.
> 
> We realize that, but one difficulty that appeared when we reviewed this
> issue during our call yesterday is that the vCard RFC uses two
> properties to denote the timezone of a given contact:
> * a UTC-OFFSET property that is defined as hh:mm difference to UTC
> * a TZ property, with an undefined format
> 
> Since compatibility with vCard is one of the design requirements of our
> API, it's not clear yet whether we can usefully define a proper timezone
> attribute (defined with a real timezone identifier), or if we are
> reduced to use the less adequate but better defined utcOffset approach.

[I may have missed some of the discussions around TZ during the call, so sorry if this was already talked through.]

Below is a summary of the supported TZ property values across vCard versions I was able to extract from the specs:

vCard 2.1: "The time zone is a string as specified in a manner consistent with ISO 8601. It is an offset from Coordinated Universal Time (UTC)." [1]. An example:

  TZ:-05:00

vCard 3.0 (RFC 2426): "The default is a single utc-offset value. It can also be reset to a single text value." [2]. Examples:

  TZ:-05:00

  TZ;VALUE=text:-05:00; EST; Raleigh/North America
  ; This example has a single value, not a structure text value.

vCard 4.0 (Internet-Draft): "The default is a single text value. It can also be reset to a single URI or utc-offset value" however "utc-offset values SHOULD NOT be used because the UTC offset varies with time" and, it "is expected that names from the public-domain Olson database will be used, but this is not a restriction" [3]. Examples:

  TZ:Raleigh/North America

  TZ;VALUE=utc-offset:-0500
  ; Note: utc-offset format is NOT RECOMMENDED.

If I read the ABNF right, all the examples from the previous versions should be also valid, albeit not recommended. AFAIK the TZ URI scheme mentioned above has not been defined yet.

WDYT in the light of this?

-Anssi

[1] http://www.imc.org/pdi/vcard-21.doc (section 2.4.5)
[2] http://tools.ietf.org/html/rfc2426#section-3.4.1
[3] http://tools.ietf.org/html/draft-ietf-vcarddav-vcardrev-15#section-6.5.1
[4] http://www.vcarddav.org/issues.xhtml#187

---------------------------------------------------------------------
This transmission (including any attachments) may contain confidential information, privileged material (including material protected by the solicitor-client or other applicable privileges), or constitute non-public information. Any use of this information by anyone other than the intended recipient is prohibited. If you have received this transmission in error, please immediately reply to the sender and delete this information from your system. Use, dissemination, distribution, or reproduction of this transmission by unintended recipients is not authorized and may be unlawful.

Received on Thursday, 20 January 2011 21:21:14 UTC