Replacement for KDateTime

[Dāvis Mosāns]

2015-08-03 20:09 GMT+03:00 Martin Klapetek <martin.klapetek at gmail.com>:
> On Mon, Aug 3, 2015 at 6:34 PM, Thiago Macieira <thiago at kde.org> wrote:
>>
>> On Monday 03 August 2015 08:33:54 Martin Klapetek wrote:
>> > > If the format you're looking for requires support from translators,
>> > > please
>> > > add
>> > > a new class to QtCore.
>> >
>> > 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.
>>
>> How would that setting be set? Who would set it? Is that something that
>> the
>> clock app would use and allow the user to set?
>>
>> If so, why not extract the time format and show that to the user? Or, at
>> least, parse it to set the default of "Use 24-hour clock"? If the user
>> wants
>> to toggle 24-hour, save the new time format in the config file and use it
>> to
>> format the time next time.
>
>
> I may have explained it poorly, so let me try again. tl;dr at the bottom :)
>
> I can put a checkbox to the Plasma panel clock which would either
> enable or disable 24h clock format. And in fact we do exactly that.
> If the user wants to see 24h clock format in the panel, he can check
> that checkbox. If he wants AM/PM clock, he can uncheck the checkbox.
> Simple as that.
>
> The implementation takes the Qt.locale().timeFormat(Locale.ShortFormat)
> (it's QML), checks for the 24h clock option and either adds "AP"
> or removes "AP" from the format string returned by Qt.locale().
> The actual clock on the panel is then printed using
> Qt.formatTime(currentTimeObject, thatModifiedTimeFormatString).
>
> Now, this will affect _only_ the Plasma panel clock. This will _not_
> affect Dolphin's time stamps, Gwenview's picture-taken times,
> this won't affect anything else but the panel clock and the panel clock
> alone. But if I want to have 24h clock format, I want it everywhere,
> in all apps, system-wide, not _only_ in the panel clock. Everything
> else will be however using time formatted by the LC_TIME locale
> default format.
>
> Currently each and every application would have to implement similar
> code as the Plasma panel clock - get the locale's time format string,
> check for some config, add/remove "AP" from the format string, print
> the time using QDateTime().toString(theModifiedTimeFormatString).
> Or each application would have to read the date/time format string
> from somewhere, some global config in order to have the same time
> format everywhere.
>
> Is it clear now? Do you see what I'm getting at?
>
> Setting different LC_TIME values proven to not be feasible, because
> very often users want "just" 24h clock format _and_ their locale's
> date format. Or some date format and their locale's time format.
>
> Ideally there would be a global setting, set from System Settings,
> perhaps written into ~/.config/QtProject.conf, which QLocale could
> internally read and return the time formatted according to that setting
> already. This would spare every single application doing it on its own.
> Then, calling QDateTime().toString() or QLocale().toString(QDateTime)
> would return the time formatted by user preference already and it would
> return it in all apps, uniformly, same format.
>
> I guess such feature might not be feasible for QLocale, hence my
> suggestion to bring back KLocale in a limited form, purely for global
> date/time formatting purposes around KDE apps, to have the same
> date/time format everywhere around.
>
> As a side note, missing global date/time format setting is a regression
> from the kde4 times.
>
> ---
>
> tl;dr - it'd be nice to be able to set a custom time format for all
> QDateTime/
> QLocale users without them needing to do anything at all.
>
> Hope it's clear now :)
>
> Cheers
> --
> Martin Klapetek | KDE Developer


What about non-Qt applications? I was thinking about this and actually it would
be a workaround for LC_ locales which are too limiting. Currently locale
can be in format language[_script][_country][.codeset][@modifier] which
represents country's standard but not user's preferences like use of 24h clock
instead of 12h.

Using @modifier for such user preferences could be one of solutions by
creating locale like en_US.UTF-8 at 24h and it would work for all applications
(note that currently QLocale ignores modifier) but what when need some other
preferences, it would become too complex as even currently locales like
de_DE at euro are used.

So better would be to introduce new variable LC_SETTINGS which would
contain a list of user preferences that override some aspects of locale and
user could use different settings than his country's locale as
currently only way
is to use different countries locale. But with such variable, user, for example,
could specify LC_SETTINGS="24h:euro" and no matter which locale
(eg. even en_US) he would always get 24h clock with euro as currency. And
mostly only libc and Qt would need this change as applications which
use standard functions like strftime would work correctly as it would be done
automatically.