Created attachment 174683 [details] File properties window Note: I'm not sure this is the right product/component at all, since this affects more than the file properties dialog See screenshot. With previous Qt versions, 'UTC+2' would be displayed for creation / access ... This also affects e.g. konversation log files: Before: [lundi 7 octobre 2024] [09:42:29 UTC+2] After: [jeudi 10 octobre 2024] [08:58:58 heure d’été d’Europe centrale]
(In reply to Christophe Marin from comment #0) > Created attachment 174683 [details] > File properties window > > Note: I'm not sure this is the right product/component at all, since this > affects more than the file properties dialog > > See screenshot. > With previous Qt versions, 'UTC+2' would be displayed for creation / access Correction, 'CEST' was displayed before
I noticed this too, with "BST" becoming "British Summer Time" - very verbose! Couldn't find a specific bug upstream, but there were a number of bug reports related to time zone parsing around versions 6.7 - 6.8, so I would guess it is on Qt's radar. https://bugreports.qt.io/browse/QTBUG-130278 <-- affects macOS but seems closest to this problem https://bugreports.qt.io/browse/QTBUG-129696 <-- KDE contributor reported a crash with Spectacle (screenshot app)
Upstream regression, closing
The specified upstream bug report is not related to this one. Please, specify a related upstream bug report or reopen this one.
From the Qt 6.8 release notes (see https://code.qt.io/cgit/qt/qtreleasenotes.git/about/qt/6.8.0/release-note.md): > dd56558ecde Date-time formats now more faithfully follow the CLDR data in handling timezones. In most cases where this changes data, it uses the IANA ID in place of the abbreviation. So it looks like this is an intentional change in Qt 6.8. Therefore, it seems reasonable to me that KIO should use its own "long" format to display the date/time. Actually, I don't see any point in displaying the timezones here at all, because the creating/modification time should be converted to the user's local timezone.
Nicolas, thoughts on this?
(In reply to popov895 from comment #5) > > So it looks like this is an intentional change in Qt 6.8. Therefore, it > seems reasonable to me that KIO should use its own "long" format to display > the date/time. Actually, I don't see any point in displaying the timezones > here at all, because the creating/modification time should be converted to > the user's local timezone. I agree. This makes sense. The code for this is at src/widgets/kpropertiesdialogbuiltin_p.cpp in the "kio" repository. It directly uses a QLocale which only has 3 format types: LongFormat, ShortFormat, NarrowFormat, confirming Qt 6.8's QLocale changed the behaviour. I didn't see a way with Qt alone to exclude the time zone when formatting, so having KIO handle a "long format without time zone" seems like a good idea. Perhaps it could be as simple as taking the time zone string (e.g. "British Summer Time") and subtracting that from the original 'long' output? (I'm just a user however, not a KDE developer) As a local hack, one could patch their own copy by forcing their desired date format: > - d->m_ui->modifiedTimeLabel->setText(locale.toString(dt, QLocale::LongFormat)); > + d->m_ui->modifiedTimeLabel->setText(dt.toString(QStringLiteral("dddd d MMMM yyyy, hh:mm:ss")));
As of kio 6.21.0, it appears the file properties window was fixed by this change: https://invent.kde.org/frameworks/kio/-/commit/b719ce072b61fefa40cd035487c981e1ededd573 However, as noted in original bug report, other places like Gwenview's Image Information still display the verbose date string (time zone).
Yes, it needs a local workaround in each affected place.