-
Enhancement
-
Resolution: Duplicate
-
P3
-
1.1.6, 1.4.2, 5.0, 6u10
-
x86
-
windows_95, windows_nt, windows_2000, windows_xp
Name: gsC80088 Date: 02/02/99
When displaying long dates, i. e. forms where the
months of the year are spelled out, the results
are incorrect for several important languages.
It looks as if the support in this area repeats
the same mistakes made by early versions of
Windows NT.
The problems are mainly in languages such as
Russian, Czech, Polish, etc. which are declined
languages. Let me give an example. Since I
can't do this in Russian in this web page, I'll
use an equivalent one from Czech.
Let's look at the date January 1, 1998, as we
would write it in English. In Czech the word for
January is leden (which is derived from the word
for 'ice'). This is the nominative case. The
problem is that there are six more forms that
this word can have.
What Java is doing is to write this as
1. leden 1998
In other words, the form assumes that the
name of the month is in the nominative case.
But, it must be in the genitive case (the 'of'
case). So this must be written as
1. ledna 1998
So, this is read as 'the first OF January 1998.
The rules for adding endings depend on the gender
of the noun and whether the ending is a soft
or hard consonant. Worse, the rules change from
one language to the next.
The same problem exists for the rest of the
months in Czech, Polish, and Russian, and
possibly for Belarus, Serbian, Croatian,
Slovenian, and Slovak. Other declined languages
are Hungarian, Romanian, and Finnish, but I think
these can be handled more easily. For example,
Finnish uses a partitive case for dates (one
possibility) and this ending is uniform.
If you want to respect local cultural conventions,
which is the goal of I18N, this needs to be fixed.
I think you would go crazy trying to write code
that declines nouns. Win32 took a different tack,
and that is to store the genitive case forms of
the months in their calendar information. You can
read them by EnumCalendarInfo.
(Review ID: 35672)
======================================================================
Name: gsC80088 Date: 03/16/99
The word for month name "May" in Russian has different
last character according to context.
When I display such a sentence:
Valid from May 1, 1997 to May 1, 2001
where the date string is generated from DateFormat
and Date class with an input of number of seconds.
The Russian date string from the same code will give
the normal "May" translation from the JDK source file
LocaleElements_ru.java as
"\u043C\u0430\u044F"
Our Russian tester points out that the last byte should
be different in the above sentences.
======================================================================
###@###.### 11/5/04 00:50 GMT
When displaying long dates, i. e. forms where the
months of the year are spelled out, the results
are incorrect for several important languages.
It looks as if the support in this area repeats
the same mistakes made by early versions of
Windows NT.
The problems are mainly in languages such as
Russian, Czech, Polish, etc. which are declined
languages. Let me give an example. Since I
can't do this in Russian in this web page, I'll
use an equivalent one from Czech.
Let's look at the date January 1, 1998, as we
would write it in English. In Czech the word for
January is leden (which is derived from the word
for 'ice'). This is the nominative case. The
problem is that there are six more forms that
this word can have.
What Java is doing is to write this as
1. leden 1998
In other words, the form assumes that the
name of the month is in the nominative case.
But, it must be in the genitive case (the 'of'
case). So this must be written as
1. ledna 1998
So, this is read as 'the first OF January 1998.
The rules for adding endings depend on the gender
of the noun and whether the ending is a soft
or hard consonant. Worse, the rules change from
one language to the next.
The same problem exists for the rest of the
months in Czech, Polish, and Russian, and
possibly for Belarus, Serbian, Croatian,
Slovenian, and Slovak. Other declined languages
are Hungarian, Romanian, and Finnish, but I think
these can be handled more easily. For example,
Finnish uses a partitive case for dates (one
possibility) and this ending is uniform.
If you want to respect local cultural conventions,
which is the goal of I18N, this needs to be fixed.
I think you would go crazy trying to write code
that declines nouns. Win32 took a different tack,
and that is to store the genitive case forms of
the months in their calendar information. You can
read them by EnumCalendarInfo.
(Review ID: 35672)
======================================================================
Name: gsC80088 Date: 03/16/99
The word for month name "May" in Russian has different
last character according to context.
When I display such a sentence:
Valid from May 1, 1997 to May 1, 2001
where the date string is generated from DateFormat
and Date class with an input of number of seconds.
The Russian date string from the same code will give
the normal "May" translation from the JDK source file
LocaleElements_ru.java as
"\u043C\u0430\u044F"
Our Russian tester points out that the last byte should
be different in the above sentences.
======================================================================
###@###.### 11/5/04 00:50 GMT
- duplicates
-
JDK-6742375 Incorrect date format for Russian locale - months names are not conjugated
-
- Closed
-
-
JDK-5053437 RFE: context sensitive months - see bug 4207993 (1999)
-
- Closed
-
-
JDK-7079560 [Fmt-Da] Context dependent month names support in SimpleDateFormat
-
- Closed
-
- relates to
-
JDK-6336885 RFE: Locale Data Deployment Enhancements
-
- Closed
-
-
JDK-6598538 Incorrect FULL DateFormat in French
-
- Closed
-
-
JDK-8046117 JEP 127: Improve Locale Data Packaging and Adopt Unicode CLDR Data
-
- Closed
-
(1 relates to)