[Interest] Question about setting QLocale

[Sebastian Wahl]

> You didn't send this email  to Sean or the list.

I wish reply all was the default action, but that just shows that you
always need to be attentive when using a new interface, be it a string
conversion API or an email client GUI, as nobody agrees on what the
default behavior should be. I will respect whatever the ones
maintaining the code decides on being the best behavior (as long they
remember to report breaking changes in the release notes).
I'm quoting both emails for the sake of keeping it public and in the
mailing list archive, I assume you don't mind.

Sebastian Wahl

On Mon, Nov 30, 2015 at 9:28 PM, Thiago Macieira
<thiago.macieira at intel.com> wrote:
> On Monday 30 November 2015 20:38:49 Sebastian Wahl wrote:
>> > You may argue whether QDateTime::toString() should have done that by
>> > default. My argument stands that QDateTime, like QString and QByteArray,
>> > should only produce predictable output (not locale-dependent).
>>
>> My argument is that the most convenient interface should fit 95 % of
>> the use cases, and the more advanced/verbose interface (using QLocale)
>> should do the remaining 5 %. Since a large focus of Qt is on GUI
>> applications, I would assume QDateTime::toString() is primarily used
>> to present the DateTime to an user, and not for implementing some
>> custom file format. It would have been the other way around if Qt was
>> mainly used as a serialization library.
>
> We'll agree to disagree. My argument is supported by the fact that you already
> need to mark all strings suitable for translation with tr(), otherwise they
> won't be translated. So the user-visible text requires more work than files.
>
>> Nevertheless it should be consistent with the documentation, which
>> says "the abbreviated localized day name" for "ddd" (for both 4.8 and
>> 5) which is consistent with the implementation in this case.
>
> Right, which is why I'm saying we missed this. We fixed QString and QByteArray
> in 5.0, but apparently missed it for QDateTime.
>
>> To Sean,
> [cut]
>
> You didn't send this email  to Sean or the list.
> --
> Thiago Macieira - thiago.macieira (AT) intel.com
>   Software Architect - Intel Open Source Technology Center
>


On Mon, Nov 30, 2015 at 8:38 PM, Sebastian Wahl <spillerrec at gmail.com> wrote:
>> You may argue whether QDateTime::toString() should have done that by default.
>> My argument stands that QDateTime, like QString and QByteArray, should only
>> produce predictable output (not locale-dependent).
>
> My argument is that the most convenient interface should fit 95 % of
> the use cases, and the more advanced/verbose interface (using QLocale)
> should do the remaining 5 %. Since a large focus of Qt is on GUI
> applications, I would assume QDateTime::toString() is primarily used
> to present the DateTime to an user, and not for implementing some
> custom file format. It would have been the other way around if Qt was
> mainly used as a serialization library.
> Nevertheless it should be consistent with the documentation, which
> says "the abbreviated localized day name" for "ddd" (for both 4.8 and
> 5) which is consistent with the implementation in this case.
>
> To Sean,
> This is why it is a  good idea to use standards, unless you have a
> very good reason not to. ISO 8601 is a good choice, especially since
> Qt supports it. Not much to do about that now though since your
> application is already in use... So I guess you have to make a
> decision on if you will change your output to a consistent correct
> output (improving and simplifying), or support both old formats
> (backwards-comparability and increased complexity). You could also
> make a converter from the old format to a new one as a compromise, but
> that might not be worth it. No silver bullet here I'm afraid...
>
> Sebastian Wahl