| Summary: | User-specific (non-root) timezone selection | ||
|---|---|---|---|
| Product: | [Applications] systemsettings | Reporter: | Luke-Jr <luke-jr+kdebugs> |
| Component: | kcm_clock | Assignee: | Paul Campbell <paul> |
| Status: | REPORTED --- | ||
| Severity: | wishlist | CC: | kde, nate, roucaries.bastien+bug |
| Priority: | NOR | ||
| Version: | 4.10.5 | ||
| Target Milestone: | --- | ||
| Platform: | Gentoo Packages | ||
| OS: | Linux | ||
| See Also: | https://bugs.kde.org/show_bug.cgi?id=443354 | ||
| Latest Commit: | Version Fixed In: | ||
| Sentry Crash Report: | |||
In what situation would different users be in different timezones on the same machine? The machine can only be in one place at a time (In reply to David Edmundson from comment #1) > In what situation would different users be in different timezones on the > same machine? > > The machine can only be in one place at a time Terminal servers... or even just user preference (I use UTC even though I live in EST5EDT) OK, I'm not super convinced, but I'm not super opposed either. Feasibility: QTimeZone internally does make a qgetenv call. KTimeZoned does not. So we're going to miss change signals, but it is in an area we can possibly change. timedated which we are switching to won't support it; that's purely session; though arguably we wouldn't need it in this case. *** Bug 201905 has been marked as a duplicate of this bug. *** |
To accomplish changing the user's local timezone for applications after KDE has been started, the TZ variable can be initialised with a path to the user's KDE config dir (eg TZ=${KDEHOME}/share/mytime). If ${KDEHOME}/share/mytime does not exist when KDE starts, it can be symlinked to /etc/localtime. Reproducible: Always