- From: Chris Toomey <ctoomey@netscape.com>
- Date: Tue, 25 Jan 2000 14:30:26 -0800
- To: www-p3p-public-comments@w3.org
- CC: me <ctoomey@netscape.com>
- Message-ID: <388E2402.8F5C9755@netscape.com>
Hi,
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.
Comments?
thx,
Chris
Received on Tuesday, 25 January 2000 17:32:36 UTC