Date pickers display "american weeks" instead of ISO weeks

I found the date pickers in "system events" and "search in serverlogs" to display american week numbers and the weeks starting with sunday.
(No matter if the AS2 client language setting is german or english.)

Since I use a german Windows with german locale settings, I would expect the weeks to start with a monday and to have the weeks numbered according to the ISO standard.

Of course, this is just a cosmetical issue.

Forum
AS2

Comments

Profile picture for user service

oh - didn't see this so far. But I think its not worth replacing the data picker just because of this..

Regards

Well, I would agree with that.
But I think that the date picker class ("com.toedter.calendar.JDateChooser") is not the problem.
I tested and found that the date picker is perfectly capable to (automatically) display a "german style calendar", as long as the locale setting is correct.

My system (german Windows 7) appears in Java with the default locale "de_DE" ... normally.
So I was surprised about how the AS2 client date picker (not) dealt with it.
After some digging I discovered this section in "de.mendelson.comm.as2.AS2" as the probable reason:

:
if (language.toLowerCase().equals("en")) {
Locale.setDefault(Locale.ENGLISH);
} else if (language.toLowerCase().equals("de")) {
Locale.setDefault(Locale.GERMAN);
} else if (language.toLowerCase().equals("fr")) {
Locale.setDefault(Locale.FRENCH);
} else {
:

The locale preset "Locale.GERMAN" represents the language code "de", but it does not represent the code for country/region "DE".
(please have a look at the source for "java.util.Locale")

I think, it's not necessary - and not a good idea - to overwrite and "simplify" the default locale to just "de", if it is already set to "de_DE" or "de_AT" e.g.
(More or less the same thoughts for "en" and "fr", when you come from "en_GB", "en_US" or "fr_FR" e.g.)

I would like the idea of the current default locale being checked before overwriting it.

What do you think ?

Regards

Profile picture for user service

freddycool,

Looks like the JRE has a problem to find out the region of the underlaying operation system.

Locale.getDefault().getCountry();

does not reflect the country in our environments of the current user nor does

System.getProperty( "user.country" );

The region is important beneath the language because the calendar is different for "en_EN" (1st day of week is Monday) and "en_US" (1st day of week is Sunday).

And if you set for example the Locale using

Locale.setDefault( new Locale(Locale.ENGLISH.getLanguage(), Locale.GERMANY.getCountry() ));

the calendar picker is displayed in the right format (english language and Monday as 1st day).

Ok thank you for the feedback so far, we are thinking about a solution.

Regards

Well, I'm not sure if this really is a "problem" of the JRE.
But as far as I was able to find out, the Java behaviour in this context has changed intentionally since Java 9.

If I understood it correctly, the idea behind that change was that the first day of week and the formula to calculate week numbers shall depend on the region but not on the language.
So, for locale "de_DE" (--> region "DE") the first day of week will be monday, but not if you specify the locale as just "de".

As a first quick-win-improvement I suggest an additional check like this:

:
if (language.toLowerCase().equals("en")) {
if (!Locale.getDefault().getLanguage().equals(Locale.ENGLISH.getLanguage())) {
Locale.setDefault(Locale.ENGLISH);
}
} else if (language.toLowerCase().equals("de")) {
if (!Locale.getDefault().getLanguage().equals(Locale.GERMAN.getLanguage())) {
Locale.setDefault(Locale.GERMAN);
}
} else if (language.toLowerCase().equals("fr")) {
if (!Locale.getDefault().getLanguage().equals(Locale.FRENCH.getLanguage())) {
Locale.setDefault(Locale.FRENCH);
}
} else {
:

I guess this should help to make sure that an already defined and very specic locale like "de_DE" will not be simplified to just "de".

What do you think ?

Regards

This seems to be "fixed" with the new version b57.
From the release notes:
"Localization possibilities extended: Possibility to define the region ..."