W3C home > Mailing lists > Public > public-i18n-core@w3.org > January to March 2015

Review of tracker issues for best practices (Part III)

From: Phillips, Addison <addison@lab126.com>
Date: Mon, 30 Mar 2015 23:52:28 +0000
To: "public-i18n-core@w3.org" <public-i18n-core@w3.org>
Message-ID: <7C0AF84C6D560544A17DDDEB68A9DFB52ECF3ABD@ex10-mbx-9007.ant.amazon.com>
Continuing from where I left off in part II.


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


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.


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)


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


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


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.


BP: Beware implicit incremental time conversions.


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?


// accept-charset usage. Needs more investigation?


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


// 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


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


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)


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

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 16:02:05 UTC