Re: New group for human-friendly dates. ICU info on the subject
- --- In ISO8601@yahoogroups.com, hjwoudenberg@a... wrote:
> The ICU (International Components for UNICODE) has allows text forday and
> month and Time Zone Abreviation. In addition:calenders,
> They allow for Islamic, Persian, Hebrew, Chinese and Japanese
> beside the Gregorian and Julian Calendar ( cut over is October 4,1582 C.E.
> ISO is only Gregorian)..etc.
> Foreign languages including right to left languages. top down
> Time may be 12 hour time (am pm)UNICODE
> Did not see any restriction that date must be only YYYY-MM-DD.
> objective is to support local languages, local formats?I'm not sure I understand how that helps. I view it as a competing
alternative that eliminates the need for standardization. If a
standard machine date object is interchanged and then locally
interpretted to an arbitrary date/time format, everyone can keep on
using different calendars and formats. I think the point of ISO8601
is, at least for commerce, everyone uses the Gregorian calendar. If
we used a standard format for dates and times, they could be
understand internationally without the need for a computer to convert
calendar or format classes. If we assume that date object is always
interchanged between computers and then interpretted, there is no
need for standardization, except the date object. However, if a
date/time format is printed out and read by humans, it needs to be
generally understand, not just by locals.
ALso, humans can exchange information without the aid of a computer,
and need to have a common international understanding of date and
time conventions, which appears to be the point of the second group,
and again support of a bunch of local standards makes the problem
Unicode is about representing and interchanging text, it's not really
ICU is a library that provides support for Unicode, but also supports
internationalization and localization functions that are typically
needed by programs and require either parsing or generating text. For
example, converting dates from an internal format to a rendering for
end-users. These functions go beyond what the Unicode standard talks
One other comment, there is more than one cutover date from Julian to
Gregorian- when the calendar was adopted varies by country and whereas
the first cuts were in 1582, the most recent occurred in some countries
in the early 1900s.
Tex Texin cell: +1 781 789 1898 mailto:Tex@...
Xen Master http://www.i18nGuy.com
Making e-Business Work Around the World
- This is another reason why computer calendars shouldn't go back
further than whenever the last changeover from Julien-Gregorian was. Either
that or store each changeover date in the OS and apply the changes
depending on whatever locale the user selects (however, this approach isn't
the best approach for people like me, who use UK English and just customise
the number settings to space for a thousands separator, currency settings
to dollars (negative looks like -1.45 $, positive looks like 1.45 $), Date
settings to yyyy-MM-dd and yyyy MMMM d '('dddd')', and Time settings to
HH:mm:ss) no matter where I am).
Maybe the OS venders should have an 'English (International)'
setting that has all this stuff already programmed? I wish this was
possible, as every time my regional settings change, I have to customise
them all over again... With an 'English (International)', the number,
currency*, date, time, and measuring systems should all match ISO settings
and the English version used should be United Kingdom... *I guess the most
common currency is the USD, so that's what it should be?
At 2004/01/27 00:01 (UTC-0500), you wrote:
>[...] there is more than one cutover date from Julian to
>Gregorian- when the calendar was adopted varies by country and whereas
>the first cuts were in 1582, the most recent occurred in some countries
>in the early 1900s. [...]
>Incoming mail is certified Virus Free.
>Checked by AVG anti-virus system (http://www.grisoft.com).
>Version: 6.0.567 / Virus Database: 358 - Release Date: 2004/01/24