Review of tracker issues for best practices (Part III)

Continuing from where I left off in part II.

http://www.w3.org/International/track/issues/84

BP: When defining calendar and date systems, be sure to allow for dates prior to the common era, or at least define handling of dates outside the most common range
// needs more detail

http://www.w3.org/International/track/issues/85

BP: When defining time or date data types, ensure that the time zone or relationship to UTC is always defined
BP: Provide a health warning for conversion of time or date data types that are "floating" to/from incremental types, referring as necessary to the Time Zones note.

http://www.w3.org/International/track/issues/87

BP: Allow for leap seconds in date and time data types. These occur occasionally when the number of seconds in a minute is allowed to range from 0 to 60 (ie. There are sixty-ONE seconds in that minute)

http://www.w3.org/International/track/issues/88

BP: use consistent terminology when discussing date and time values. Use 'floating' time for time zone independent values.
// more detail needed here
// since some programming and markup languages have developed a concept of "local time", it's probably time to start revision of the time zone note

http://www.w3.org/International/track/issues/89

BP: when defining a "local time" value, provide a means of relating the data type to UTC

http://www.w3.org/International/track/issues/92

BP: keep separate the definition of time zone from time zone offset.
BP: Use IANA time zone IDs to identify time zones. Do not use offsets or LTO as a proxy for time zone.
BP: Use a separate field to identify time zone.

http://www.w3.org/International/track/issues/93

BP: Beware implicit incremental time conversions.

http://www.w3.org/International/track/issues/94

BP: when defining rules for a "week", allow for culturally specific rules to be applied. For example, the weekend is not always Saturday/Sunday; the first day of week is not always Sunday [or Monday or...], etc.
BP: when defining rules for week number of year, allow for culturally specific rules to be applied.
// cf. CLDR data?

http://www.w3.org/International/track/issues/95

// accept-charset usage. Needs more investigation?

http://www.w3.org/International/track/issues/96

BP: when defining email field validation, allow for EAI (smtputf8) names

http://www.w3.org/International/track/issues/97

// this is effectively the page about locale affected formats in our wiki + LTLI work
// if I had to write a BP now, it would be something like:
BP: when data values in a page are displayed, define their formatting and presentation be set according to the language attribute

http://www.w3.org/International/track/issues/98

BP: when non-Gregorian calendars are permitted, note that the "month" field can go to 13 (undecimber)

http://www.w3.org/International/track/issues/101

BP: when parsing user input of numeric values, allow for digit shaping (non-ASCII digits)
BP: when formatting numeric values for display, allow for culturally sensitive display, including the use of non-ASCII digits (digit shaping)

http://www.w3.org/International/track/issues/103

BP: when defining terms related to strings, characters, code points, encodings and so forth, refer explicitly to Charmod. Quote the definitions used there.
Charmod == http://www.w3.org/TR/charmod



Addison Phillips
Globalization Architect (Amazon Lab126)
Chair (W3C I18N WG)

Internationalization is not a feature.
It is an architecture.

Received on Monday, 30 March 2015 23:53:01 UTC