Bug 494521

Summary: Behaviour change with timezones in Qt 6.8
Product: [Frameworks and Libraries] frameworks-kio Reporter: Christophe Marin <christophe>
Component: Properties dialogAssignee: KIO Bugs <kio-bugs-null>
Status: CONFIRMED ---    
Severity: normal CC: code, kdelibs-bugs-null, nate, nicolas.fella, popov895, smowtenshi
Priority: NOR Keywords: regression
Version First Reported In: unspecified   
Target Milestone: ---   
Platform: Other   
OS: Linux   
URL: https://bugreports.qt.io/browse/QTBUG-130278
Latest Commit: Version Fixed/Implemented In:
Sentry Crash Report:
Attachments: File properties window

Description Christophe Marin 2024-10-11 10:54:50 UTC
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]
Comment 1 Christophe Marin 2024-10-11 13:36:46 UTC
(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
Comment 2 Luke Horwell 2024-10-20 22:58:56 UTC
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)
Comment 3 Christophe Marin 2024-10-23 10:03:40 UTC
Upstream regression, closing
Comment 4 popov895 2024-11-17 14:05:30 UTC
The specified upstream bug report is not related to this one. Please, specify a related upstream bug report or reopen this one.
Comment 5 popov895 2024-11-17 21:30:34 UTC
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.
Comment 6 Christophe Marin 2024-11-28 16:31:57 UTC
Nicolas, thoughts on this?
Comment 7 Luke Horwell 2025-03-09 15:28:37 UTC
(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")));
Comment 8 Luke Horwell 2025-12-13 22:30:51 UTC
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).
Comment 9 Nate Graham 2025-12-16 21:20:30 UTC
Yes, it needs a local workaround in each affected place.