Replacement for KDateTime

Ben Cooksley bcooksley at
Tue Aug 4 06:52:18 BST 2015

On Tue, Aug 4, 2015 at 8:57 AM, John Layt <jlayt at> wrote:
> On 3 August 2015 at 07:33, Martin Klapetek <martin.klapetek at> wrote:
>> So what is missing/wanted is telling QLocale to use en_GB *but* return
>> any time string in 24h format for example. Or to use ISO date format
>> by default. The stuff coming from cldr might not always be what
>> the user wants. And there's no easy and global way to override it
>> other than setting different LC_TIME value, which is less than ideal
>> as it can give you 24h clock format but will leave you with different
>> date format too, so it's a hit'n'miss game.
>> Suppose there's such QLocale setting as described above, then it would
>> be just a matter of some regexp inside the time formatting function which
>> would add/remove the "ap"/"AP" strings for the clock. I imagine.
> There's code that does that floating around in KDE or Qt, can't recall
> where, but it is fraught with problems in unconventional languages.
> You also need to replace the hh with HH to get the 24 rather than 12.
> But it's a hard rule in QLocale: no overriding default settings
> provided by the system, as those are the system settings and what the
> user expects you to use, e.g. on Windows and Mac you can switch from
> 12 to 24 hours and have it respected by Qt. If you want a different
> format, then pass a custom pattern each time.
> The problem actually is that Plasma is not considered a system
> platform by QLocale, it doesn't go looking for what Plasma wants, it
> just uses the underlying GNU/Linux system settings. Convince Qt to
> hard-code in a lookup of some Plasma config file with user overrides
> to be applied whenever Qt apps run under Plasma and then you can get
> what you need. I had plans somewhere for how that would work, and how
> we could also make Gtk apps use our settings too by manipulating the
> LC_* settings.

I'm assuming QLocale isn't routed through the platform plugin like
other parts of Qt do in these cases, so we can't manipulate things

> John.


More information about the kde-core-devel mailing list