W3C home > Mailing lists > Public > www-p3p-public-comments@w3.org > January 2000

Time zones in base data schema

From: Chris Toomey <ctoomey@netscape.com>
Date: Tue, 25 Jan 2000 14:30:26 -0800
Message-ID: <388E2402.8F5C9755@netscape.com>
To: www-p3p-public-comments@w3.org
CC: me <ctoomey@netscape.com>

Couple suggestions re: timezone representation in the base data schema.

1. You specify only "text" as the type for the date.timezone field,
whereas this could be specified more precisely (like country code is).

In general it seems like the more precisely these data fields can be
specified, the more useful they'll be for interchange.  Was there a good
reason for being noncommital about format, or if not, how about
committing to a standard representation?

There seem to be at least a couple choices for the representation,
though I am only 1 day into looking at timezone reprs. and may not be
aware of other stds.

     A. The ISO 8601-style format described at
     http://www.w3.org/TR/NOTE-datetime .  This is an
     offset-from-GMT format that would be good for expressing a
     user's current timezone offset (factoring in DST, etc.), but
     wouldn't be so good for a permanent representation of a user's
     timezone (as the offset changes over time due to DST).

     B. The "zoneinfo" database representation and implementation,
     used by several Unix systems, described at
     http://www.twinsun.com/tz/tz-link.htm .  This combines a
     representation for locations spanning the different time zones
     (e.g., "America/New_York") as well as data tables and code to
     dynamically convert that into the DST-adjusted GMT offset.

Perhaps both styles should be represented in the date. element, e.g.,
date.timezone_offset, data.timezone_zone.

2. Lots of sites request the user's timezone, yet you don't have that
represented as part of your user. schema, other than perhaps
accidentally as a field in the birthday element.

I'd suggest adding it to either user. (user.timezone*), or contact.
(user.home.timezone*, user.business.timzeone*), and again using a
standardized, precise representation instead of text.



Received on Tuesday, 25 January 2000 17:32:36 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 22:42:59 UTC