Date input is based on 1900

[Poncho]

Hi there

When crating a new season, the date `01.01.24` is translated to `01 Jan
1924` instead of `01 Jan 2024`

This happens on other date input fields as well.

I think this could be fixed by the displayFormat property
(https://doc.qt.io/qt-6/qdatetimeedit.html#displayFormat-prop) of
QDateEdit (https://doc.qt.io/qt-6/qdateedit.html)

The date format throughout the code is inconsistent though. Both
setDisplayFormat("yyyy-MM-dd") and setDisplayFormat("dd/MM/yyyy") are used.

Which one is preferred?

Or is there a more general fix?

https://doc.qt.io/qt-6/qdatetimeedit.html#displayFormat-prop also
mentions the default century:

> Note that if you specify a two digit year, it will be interpreted to be in the century in which the date time edit was initialized. The default century is the 21st (2000-2099).

Best regards,
Poncho

[Poncho]

Looks like this is an issue introduced with qt6.

It doesn't happen with the appimage.

[Ale Martinez]

I cannot reproduce this on my local build using Qt 6.6.3:

[Poncho]

I think it's related to the change between 6.6 and 6.7 mentioned bellow:

https://doc.qt.io/qt-6/whatsnew67.html

> Date (and datetime) parsing of two-digit years now allows the caller to control the century within which those years are selected.

I'm building with Qt 6.7.3

[Ale Martinez]

El miércoles, 27 de noviembre de 2024 a la(s) 5:16:25 p.m. UTC-3, Poncho escribió:

I think it's related to the change between 6.6 and 6.7 mentioned bellow:

https://doc.qt.io/qt-6/whatsnew67.html

> Date (and datetime) parsing of two-digit years now allows the caller to control the century within which those years are selected.

I'm building with Qt 6.7.3

But that doesn't explain the change in default century, does it?

[Poncho]

On 28.11.24 13:40, Ale Martinez wrote:
> But that doesn't explain the change in default century, does it?

I don't understand it either.

Version 6.7 introduced the baseYear parameter with the
DefaultTwoDigitBaseYear value as default
https://pages-test.qt.io/qt-6.7/qdate.html#static-public-members

While the default is 1900, it's now allowed to be overwritten by some qt
functions and system locales.
https://doc.qt.io/qt-6/qlocale.html#DefaultTwoDigitBaseYear-var

> Some locales use, particularly for ShortFormat, only the last two digits of the year. Proir to 6.7 the year 1900 was always used as a base year for such cases. Now various QLocale and QDate functions have the overloads that allow callers to specify the base year, and this constant is used as its default value.

[Poncho]

The issue is the interaction between qt and the system locale:

With LC_TIME=en_US.UTF-8 I get a two digit year starting at 1900
With LC_TIME=de_CH.UTF-8 I get a two digit year starting at 1900
With LC_TIME=C.UTF-8 I get a four digit year starting at 2000

It's either a change or a regression in qt 6.7

This bug mentions the two-digit-issue. But not the century problem.
https://bugreports.qt.io/browse/QTBUG-122216

It's a mess, but not a bug in GC

[Ale Martinez]

Thank you for the investigation, I installed 6.7.3 on Windows 11 and i cannot reproduce the issue using USA/English or AR/Spanish regional settings.

[Ale Martinez]

El miércoles, 11 de diciembre de 2024 a la(s) 3:08:16 p.m. UTC-3, Ale Martinez escribió:

Thank you for the investigation, I installed 6.7.3 on Windows 11 and i cannot reproduce the issue using USA/English or AR/Spanish regional settings.

Not strictly related to the OP, but after updating my Windows build to Qt 6.7.3 I found this issue on Windows 11, it seems to remain unsolved: https://bugreports.qt.io/browse/QTBUG-124150  

[Ale Martinez]

El miércoles, 11 de diciembre de 2024 a la(s) 3:08:16 p.m. UTC-3, Ale Martinez escribió:

Thank you for the investigation, I installed 6.7.3 on Windows 11 and i cannot reproduce the issue using USA/English or AR/Spanish regional settings.

Not so much... I got bitten by this yesterday...

Even when you can avoid the issue using the popup calendar is pretty annoying and we should look for a workaround if we want to produce an official build using latest Qt6.x

[Poncho]

On 29.01.25 14:03, Ale Martinez wrote:
> we should look for a workaround if we want to produce an
> official build using latest Qt6.x

This is fixed in Qt 6.8.2

https://code.qt.io/cgit/qt/qtreleasenotes.git/about/qt/6.8.2/release-note.md#fixes

[REG 5->6] QDateEdit defaults to 20th century
https://bugreports.qt.io/browse/QTBUG-126698

[Ale Martinez]

Have you been able to build using 6.8 on Linux?

I tried on Windows 11 with both MSVC 2019 and 2022 and QWebEngine modules doesn't seem to be included in standard pre-build distributions, unlike previous versions up to 6.7.

[Poncho]

On 05.03.25 23:53, Ale Martinez wrote:
> Have you been able to build using 6.8 on Linux?

Yes, I'm building git master with QT 6.8.2 and the patches from
https://github.com/GoldenCheetah/GoldenCheetah/pull/4609

I don't know about the standard pre-build version of QT since I'm using
the system-installed libraries of my Linux distribution.

[Poncho]

On 05.03.25 23:53, Ale Martinez wrote:

> I tried on Windows 11 with both MSVC 2019 and 2022 and QWebEngine modules
> doesn't seem to be included in standard pre-build distributions, unlike
> previous versions up to 6.7.

I haven't checked it my self... but apparently, WebEngine has to be
selected unter the extension tab since version 6.8

Might be your issue.

https://stackoverflow.com/questions/79299905/qt-6-8-linux-gcc-webengine-is-missed

> Starting with Qt 6.8.0, the WebEngine is hidden under Extensions and is not part of Qt folder anymore. Whoever thought that this is a good idea.

[Ale Martinez]

Yes, that was the problem for my local builds, thank you :(

Now I think AppVeyor maintainers have fallen on the same trap since WebEngine is neither available on Windows images' preinstalled Qt 6.8.1