IssueTracker

I need to understand where the DatePicker takes its weekday names from. There are various issues with weekday names, it could be one of them.

Interestingly the first day of the week is sometimes Monday sometimes Sunday depending on devices in Locales CHINESE/CHINA/ENGLISH, it could be that some of our emulators are incorrectly set-up though.

I will try to explain the issue as best as I can given that I cannot read nor understand chinese.

Week days in java.time (JDK8 and onwards, Android 26+) can be expressed in 3 forms: NARROW (1 letter), SHORT (~3 letters) and LONG (As many letters as necessary).

Week days in java.text (old api) can be expressed in 2 forms, SHORT and LONG.

Desugared library should work on Android version below 26. We built a compatibility layer so that the new api get the correct weekday names from the old api to work on older devices. To avoid different behaviors in between devices, desugared library always use when enabled the compatibility layer and therefore always go through the old api. For SHORT and LONG styles, the old api had already the names, so we just use that and it seems to be correct. Now for NARROW, the old api does not have the name for the NARROW style. So we decided to use the first character of the long name. You can see this here: https://github.com/google/desugar_jdk_libs/blob/master/jdk11/src/java.base/share/classes/java/time/format/DateTimeTextProvider.java#L459C17-L460C41

Now it's very likely that the original implementer (and myself) spoke only languages where using the first character of the long name as the narrow name is fine (I'm fluent in French and English). Now I have printed the week day names in English and Chinese as a comparison:

Narrow: MTWTFSS Long: Monday Tuesday Wednesday Thursday Friday Saturday Sunday

Narrow: 一二三四五六日 Long: 星期一 星期二 星期三 星期四 星期五 星期六 星期日

With desugared library, the narrow format is correct in English (and French and many others) but in Chinese it gets the first character of each long name, which is: 星星星星星星星. It seems what you would expect is in fact the last character.

Recently we reworked the month names, and a similar issue occurs, it seems the Chinese language uses numbers as narrow names:

Narrow: 123456789101112 Long: 一月 二月 三月 四月 五月 六月 七月 八月 九月 十月 十一月 十二月

Narrow: JFMAMJJASOND Long: January February March April May June July August September October November December

With desugared library, the narrow format is also the first character hence in Chinese: 一二三四五六七八九十十十. I have no idea if that makes sense to you guys, does it?

It's not clear to me what we should do here. We could fix it on runtimes on 26+, but then developers may be confused by the fact that it does not work as expected in Android 25-. I don't really know how to check if it makes sense for a language to use the first character for the narrow format or not.

@deltazulu you speak Chinese don't you? What do you think? Can we do something about this?

Yes, I understand the regression. We're going to try to get the correct day names to work in Chinese, we have to evaluate what we can do.

For firstDayOfWeek, it's also different on some Android versions on my emulators such as 4.0.4 and 14 (Monday instead of Sunday). It might be possible to change the non desugared data somewhere to change the default first day of the week, likely when the Android vendor builds the java library. In addition, most libraries have methods such as setFirstDayOfWeek to work around this. Desugared library picks the first day on a given version (typically Java 11 or Android 13) which is then backported and always consistent when using desugared library disregarding the underlying device android version.

Interesting, for weekday names in Mandarin Chinese, it would make more sense to take the last Chinese character from the long name as the short name. They are basically numbers except for Sunday whose short name means "Sun". I think this part applies to both traditional and simplified Chinese scripts. (I personally speak Mandarin Chinese and write in simplified Chinese).

• 星期一 -> 一
• 星期二 -> 二
• 星期三 -> 三
• 星期四 -> 四
• 星期五 -> 五
• 星期六 -> 六
• 星期日 -> 日

For the first day of the week, my recollection is Sunday goes first more common though there is a mixed patterns.

For months,

1. 一月
2. 二月
3. 三月
4. 四月
5. 五月
6. 六月
7. 七月
8. 八月
9. 九月
10. 十月
11. 十一月
12. 十二月

For Oct, Nov, Dec, I don't see any good single-character fit. "十一" means "10 + 1“ and "十二" means ”10 + 2“, they will become ambiguous with "十" if taken the first character as the short name.

More often I see is Chinese are using numerical for dates:

• 2023-09-14 --> 2023年9月14日

Opened b/307200757 on making the single letter weekday customizable in the DatePicker.

@clementbera re: comment #2, I've added the code locations where we read the day's letter here.

On API 26+ we read a single letter with ...getDisplayName(TextStyle.NARROW...), and API < 26 we read the shortWeekdays, which gives us 3-letters per day.

See b/315934582 (Similar issue with Hebrew)

They fixed it using DayOfWeekFormatting.formatNarrow from i18n/format/time, which works from 24 instead of 26.

Working towards a solution in b/307200757.

DayOfWeekFormatting.formatNarrow uses android.icu.text.DateFormat.getInstanceForSkeleton("ccccc", locale). For Locale.CHINA (zh_CN), that agrees with comment #3:

• 一
• 二
• 三
• 四
• 五
• 六
• 日

If I use the same approach and some locale to request a narrow month name (with a skeleton of either "LLLLL" or "MMMMM", both of which I imagine get normalized to the same thing when used as the sole piece of information in a pattern), I get results that likewise agree with comment #3:

• 1
• 2
• 3
• 4
• 5
• 6
• 7
• 8
• 9
• 10
• 11
• 12

Any updates on this? Is using platform code on API 26+ an option?

Any update on this? We are seeing the same problem in the Fitbit app (see b/350954005), and the Flex Catalog app which uses the Material DatePickerDialog

We have made several upgrade to the date data filling. Do you still see the issue? If so, please post your test case with both the actual and expected result in this thread.

Project: r8
Branch: main
Author: Søren Gjesse <sgjesse@google.com>
Link:      https://r8-review.googlesource.com/97623

Reproduce Chinese NARROW weekday issue with desugared library

Reproduce Chinese NARROW weekday issue with desugared library 
 
Bug: b/300128109 
Change-Id: I0affac8e3e72b2ba09939d7b242a714c79461078

Project: r8
Branch: main
Author: Søren Gjesse <sgjesse@google.com>
Link:      https://r8-review.googlesource.com/97703

Skip Chinese NARROW weekday test on Windows when running in the JVM

Skip Chinese NARROW weekday test on Windows when running in the JVM 
 
Bug: b/300128109 
Change-Id: Ia4179bc1b48c75a5319115bc4a3f63a060621fd2

Project: r8
Branch: main
Author: Søren Gjesse <sgjesse@google.com>
Link:      https://r8-review.googlesource.com/97666

Prepare for release of desugared library 2.1.3

Prepare for release of desugared library 2.1.3 
 
Bug: b/300128109 
Change-Id: Ia00b964352db964412dc3ed1812a4d0c36f0ae56

Version 2.1.3 of desugared library has been released with a fix for TextStyle.NARROW_STANDALONE using the last code point as shown in comment #6.

When using TextStyle.NARROW this is not applied (as shown by https://r8.googlesource.com/r8/+/45352d89c890ca87ec845d82cea94887d013e170/src/test/java/com/android/tools/r8/desugar/desugaredlibrary/DayTest.java#93).

Any developers waiting for this fix, please check out the fix for TextStyle.NARROW_STANDALONE and comment on TextStyle.NARROW expectations.

There's no difference between the "stand-alone" and "standard" forms in Chinese. So I would expect TextStyle.NARROW to have the same behavior as TextStyle.NARROW_STANDALONE.

Project: r8
Branch: main
Author: Søren Gjesse <sgjesse@google.com>
Link:      https://r8-review.googlesource.com/99764

Fix tests for desugared library 2.1.4

Fix tests for desugared library 2.1.4 
 
Bug: b/300128109 
Change-Id: I90fe05365f2fe7a6ead6c7f48fcfeb06e90cd1de

Project: r8
Branch: main
Author: Søren Gjesse <sgjesse@google.com>
Link:      https://r8-review.googlesource.com/99783

Prepare for release of desugared library 2.1.4

Prepare for release of desugared library 2.1.4 
 
Bug: b/300128109 
Change-Id: I9e585694bcebb5c87785bac881202c64c1f9fd49