- 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