From: Mark Davis (mark.davis@jtcsv.com)
Date: Fri May 07 2004 - 19:28:18 CDT
If you look at LDML, you will see that it uses a narrow view of locale;
essentially those elements that are language-specific + variations (like choice
of phonebook vs dictionary collation for German). In particular, a locale does
not include a time zone, nor does it include a currency; those are considered
orthogonal attributes. What an LDML locale does include is the capacity to have
*translated names* for time zones, and *translated names* for currencies.
If someone wants to build a broader notion of locale on top of this they could
do so, incorporating whatever other information is important for the given
transactional processing, e.g., customer timezone, nearest branch office
timezone, customer's preferred currencies, vendor's allowed currencies, seat
assignment, dietary restrictions (kosher, atkins, no vegetables beginning with
the letter C, ...), security status (low-, medium-, high-risk), religious
preference (atheist vs theist), etc.
Mark
__________________________________
http://www.macchiato.com
► शिष्यादिच्छेत्पराजयम् ◄
----- Original Message -----
From: "Carl W. Brown" <cbrown@xnetinc.com>
To: "Unicode List" <unicode@unicode.org>
Sent: Fri, 2004 May 07 14:46
Subject: RE: TR35 (was: Standardize TimeZone ID
> Mark,
>
> > That is not a problem. The Olson IDs are not guaranteed
> > to be unique, just unambiguous. And there are aliases.
> > Typically these are de-unified for political
> > purposes. Thus you may find that two different IDs produce
> > the same results over
> > the entire period of time in the database.
>
> So which timezone will the tr_TR locale in a TR35 database have?
"Asia/Istanbul" or "Europe/Istanbul" or both?
>
> I guess that the territory possessions list should be an another database that
is merged.
>
> Carl
> >
>
>
>
>
>
This archive was generated by hypermail 2.1.5 : Fri May 07 2004 - 19:28:52 CDT