Klock french localization abbreviates June and July to same string

[dalewking]

In the French locale, format EEE for the short form of month names will output the same text for both June and July. In French those month names are "juin" and "juillet". The Locale code is just abbreviating to 3 characters which is the same for both months.

[soywiz]

what's the correct abbreviation for June and July in French?

[dalewking]

I am not a French expert, I just discovered this as part of migrating our project away from Klock for formatting for several reasons (like some languages we need not being supported). I know we can create our own KlockLocale but we intend to switch to Kotlinx-Datetime any way. So we are in the process of switching to use the underlying platform for doing formatting (using java.time and NSDateFormatter). So in that process I cataloged the differences after switching from Klock to the platform specific formatting.

So here is all the differences after switching to the platform formatting for the languages that we use:

• English
  • am/pm are now all caps AM/PM
• Spanish
  • a.m/p.m get a non-breaking space between the . and the m (Android is a normal non-breaking space and iOS is a narrow one)
  • September is abbreviated to sept instead of sep
  • On Anddoid there is a period after the abbreviation for month and day names but iOS does not
• French
  • Short Day names now have a period after the abbreviation (e.g. lun.)
  • Month names used to be abbreviated to first 3 letters which lead to June and July both being abbreviated to “jui”
  • Month abbreviations are now:
    • janv.
    • févr.
    • mars
    • avr.
    • juin
    • juil.
    • août
    • sept.
    • oct.
    • nov.
    • déc.
• German
  • Now uses AM/PM instead of vorm. and nachm.
  • Short day names used to be first 3 letters of Day name, now it is first 2 letters plus a period
  • Short month names now are first 3 letters of month with a period except for these months:
    • März
    • Juni
    • Juli
    • Sept.
• Dutch
  • Short day names used to be first 3 letters of Day name, now it is first 2 letters (no period)
  • Shortened month names used to just be first 3 letters of month name. They now get a period after the abbreviation and March (maart) is abbreviated as:
    • mrt.
• Portugese
  • Shortened Day and month names now have a period after the abbreviation

[soywiz]

Thanks! That's really useful. We can try to improve consistency here with that info.

BTW: Which languages did you need that were not supported?

[dalewking]

At the moment only Finnish, but we will probably be adding others soon.

[soywiz]

BTW just out of curiosity: why are you investing in using native formatters instead of keeping using the old but working klock version and waiting for kotlinx-datetime to include date formatters?

[dalewking]

Because our future does not involve Klock, we are switching to kotlinx-datetime, but as an app that is primarily dealing with schedules it is a large tear-up to switch so will take a while. I am not confident that kotlinx-datetime will support formatting and I'm not even sure they should.

In several ways Klock doesn't work well for us with formatting:

• It only supports a limited number of localizations as we found out with Finnish
  • though more could be added the native platform will always support all languages
  • This also handles cases where a device's primary language is one that your app does not support. It will still format in the user's chosen language
• The setting of KlockLocale to change Klock formatting language is problematic.
  • as languages are added requires adding code to update KlockLocale for the new language.
  • when does one update the KlockLocale? Our app currently does it at startup, but if you change the language while the app is running it does not update
• I am leery about how well supported Klock is considering a recent DST bug I reported and now that it is just a small part of a gaming engine

I have a really good solution now that formats kotlinx datetime local date and time values that is mixed with Moko-Resources, using its paradigm for when to apply Locale.

[soywiz]

I believe if it is just for formatting, we could just provide a DateFormatter that uses the native formatter for each platform:

DateFormat is just an interface: https://github.com/korlibs/korge/blob/c37453aaabf76f46bb92f4a918e6f82f1a6fb804/klock/src/commonMain/kotlin/korlibs/time/DateFormat.kt#L4

We could implement it for iOS/Android/JVM and JS like a SystemDateFormat. If you are going to implement it, feel free to make a PR. We can integrate it. If you have an app that is actually doing heavy stuff with date and time, that implementation might be a good base for iterating it.

Klock might also eventually depend on kotlinx-datetime. For now there is a step towards using Duration here: https://github.com/korlibs/korge/pull/1596

Regarding to "game engine": It is not the case. Libraries are still independant. The main reason I have them in a single repo is that as the main contributor, it is much faster and easier for me to iterate the libraries / update buildscript code like this. But they are still independant and designed like that so people not requiring the game engine could still benefit from all those libraries and code.

The rational why it is here: Klock is released under public domain. I created it along the other libraries because when I started there were no such libraries and not alone with the functionalities I needed for the game engine. But I wanted, and tried several times, to give them away to the Kotlin ecosystem/fundation, and public domain was the only way I was able to do that in practice. kotlinx-coroutines ended being useful for asynchronous functionality and made the libraries use it, as well as kotlinx-serialization, but for example, kotlinx-io was really lacky in what I needed in practice. And ktor was not really multiplatform when I needed it.

It is fine if you already did or eventually decide to switch, but if you want to keep using it, this repo is really welcoming to add new functionality, ideally through PRs since my bandwidth is limited. And in any case: even with its limitations, glad it was useful for you all this time!

[dalewking]

Not trying to disparage your library and you can probably fix the problems, but the bottom line is you definitely don't have the resources the JetBrains has, so I trust them more to get it right.

My solution for formatting is not as general purpose to fill your needs and is tied with Moko Resources.

I also kind of think the model used by kotlinx-datetime is less error prone than Klock. We have battled this in tests many times with tests that fail after 8PM Eastern to do problematic conversions from UTC to Local. When we have code that does things like someDateTime.local.local (or is that someDateTime.local.utc that is an indication of of a problem. And Klock does not have adequate TimeZone support which meant we had to have kotlinx-datetime any way.

[soywiz]

We have battled this in tests many times with tests that fail after 8PM Eastern to do problematic conversions from UTC to Local.

Can you provide an specific scenario + code where it is failing?

When we have code that does things like someDateTime.local.local (or is that someDateTime.local.utc that is an indication of of a problem.

That part is indeed confusing. It is something that can be changed and improved. We can deprecate old behaviour and redirect to a new one. Based on your experience, do you have a specific idea on how could it be improved to be less confusing?