https://bugs.kde.org/show_bug.cgi?id=483879
Méven Car <[email protected]> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|REPORTED |NEEDSINFO Resolution|--- |WAITINGFORINFO CC| |[email protected] --- Comment #3 from Méven Car <[email protected]> --- I looked into this and could not find a code path in Dolphin where the modification time is treated as UTC. All three date paths read the raw mtime epoch and convert it with the single-argument QDateTime::fromSecsSinceEpoch(), which returns a local-time QDateTime. I reproduced your exact scenario in a small test: a file modified Sun 2024-03-17 22:00 local in a UTC-4 zone (which is Mon 02:00 UTC), with "today" being Monday: - TZ=America/New_York: file groups under "Yesterday" (Sunday) -> correct - TZ=UTC: file groups under "Today" (Monday) -> the behavior you describe So the grouping is correct as long as the process resolves a real local timezone. The wrong-day result only appears when the running process's effective timezone is UTC. That points to a timezone-resolution problem in the session/environment rather than a Dolphin bug. This also matches the fact that 24.02 and current master are identical in this code. A few things that would help confirm: 1. What does date print in the same shell you launch Dolphin from? Does it show your local zone or UTC? 2. Is /etc/localtime a symlink to your zone (e.g. ls -l /etc/localtime)? 3. Are you running Dolphin from a Flatpak/sandbox? Sandboxes sometimes do not pass the host timezone through, so the app sees UTC. 4. If you launch with an explicit zone, e.g. TZ=America/New_York dolphin, does the grouping become correct? If the grouping is correct with an explicit TZ, this is an environment/timezone-database issue rather than a Dolphin defect. -- You are receiving this mail because: You are watching all bug changes.
