https://bugs.kde.org/show_bug.cgi?id=340982
Flupp <bugs.kde....@derflupp.e4ward.com> changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |bugs.kde.org@derflupp.e4war
| |d.com
--- Comment #231 from Flupp <bugs.kde....@derflupp.e4ward.com> ---
Just adding another data point:
(In reply to Nate Graham from comment #214)
> […]
> As I said, if we do our own thing to fix it for only KDE apps, or only for
> Qt apps, we make apps' presentation of formats inconsistent across the OS.
> […]
In corner cases, it already *is* inconsistent.
I was desperately trying to find a locale where Qt/KDE *and* the rest of my
system use ISO date format and 24h time format. I failed. And I now understand
why:
(In reply to Kevin Kofler from comment #220)
> […] Qt does not actually use POSIX locales
> internally, but ICU locales, and has a hardcoded mapping from POSIX to ICU
> locales. […]
It seems that mapping is not (and probably cannot be) perfect.
I worked around the problem as follows: It turned out that for Qt/KDE there is
the en_SE locale, which provides the format I want, but that locale does not
exist in the POSIX world. However, for POSIX the de_BE locale provides the
format I want. So I ended up creating an en_SE POSIX locale by simply
symlinking en_SE to de_BE and using en_SE system-wide (i.e., in the Qt/KDE
world as well as in the POSIX world) for date and time. It is still not perfect
because long date format is still inconsistent, but I can tolerate that.
PS: In case this is relevant: I am using Arch Linux.
PPS: If you search for an alternative POSIX locale providing ISO date format,
here is a list:
> localectl list-locales | while IFS='' read -r; do echo -n "$REPLY | ";
> LC_TIME="$REPLY" date -d '2022-01-03 13:02:01' '+%a | %A | %b | %B | %c | %p
> | %r | %x | %X'; done | grep '| ....-..-.. | ..:..' | column -ts'|'
>
> csb_PL.UTF-8 pòn pòniedzôłk stë stëcznika pòn 03
> stë 2022 13:02:01 01:02:01 2022-01-03
> 13:02:01
> de_AT.UTF-8 Mo Montag Jän Jänner Mo 03
> Jän 2022 13:02:01 01:02:01 2022-01-03
> 13:02:01
> de_BE.UTF-8 Mo Montag Jan Januar Mo 03
> Jan 2022 13:02:01 01:02:01 2022-01-03
> 13:02:01
> de_LU.UTF-8 Mo Montag Jan Januar Mo 03
> Jan 2022 13:02:01 01:02:01 2022-01-03
> 13:02:01
> en_CA.UTF-8 Mon Monday Jan January Mon 03
> Jan 2022 01:02:01 PM PM 01:02:01 PM 2022-01-03
> 01:02:01 PM
> en_DK.UTF-8 Mon Monday Jan January
> 2022-01-03T13:02:01 CET 01:02:01 2022-01-03
> 13:02:01
> eo.UTF-8 lun lundo Jan Januaro lun 03
> Jan 2022 13:02:01 01:02:01 2022-01-03
> 13:02:01
> fr_CA.UTF-8 lun lundi jan janvier lun 03
> jan 2022 13:02:01 01:02:01 2022-01-03
> 13:02:01
> hu_HU.UTF-8 h hétfő jan január 2022.
> jan. 3., hétfő, 13:02:01 CET 13:02:01 2022-01-03
> 13:02:01
> lt_LT.UTF-8 Pr Pirmadienis saus. sausio 2022
> m. sausio 03 d. 13:02:01 01:02:01 2022-01-03
> 13:02:01
> nan_TW.UTF-8@latin p1 pài-it 1g 1goe̍h 2022
> 1g 03 (p1) 13:02:01 CET ē-po͘ 01:02:01 ē-po͘ 2022-01-03
> 01:02:01 ē-po͘
> se_NO.UTF-8 vuos vuossárga ođđj ođđajagemánnu vuos,
> ođđj 3. b. 2022 13:02:01 CET 01:02:01 2022-01-03
> 13:02:01
> si_LK.UTF-8 ස සඳුදා ජන ජනවාරි
> 2022-01-03 13:02:01 +0100 ප.ව. ප.ව. 01:02:01 2022-01-03
> 13:02:01
> sv_SE.UTF-8 mån måndag jan januari mån 3
> jan 2022 13:02:01 01:02:01 2022-01-03
> 13:02:01
> wae_CH.UTF-8 Män Mäntag Jen Jenner Män
> 03. Jen 2022 13:02:01 CET 01:02:01 2022-01-03
> 13:02:01
--
You are receiving this mail because:
You are watching all bug changes.
