Bug 355858

package of plasma-workspace is 4:5.4.2-1+b1
This version can not be selected from the “Version” dropdown.

I've seen this before where the users /etc/localtime was broken

Can you show me the output of "ls -l /etc/localtime"

Sure

> ls -l /etc/localtime
-rw-r--r-- 1 root root 2309 Okt  7 17:51 /etc/localtime

It is set to Europe/Berlin.
Setting it to Europe/Helsinki temporarily does not help.

I tried the version from git. Does not work either.

That's not right, it should be a symlink to somewhere in /usr/share/timezone

like this: 

lrwxrwxrwx  1 root root     35 Oct 17 09:19 localtime -> ../usr/share/zoneinfo/Europe/London

That’s probably distribution dependent.
On Debian “dpkg-reconfigure tzdata” copies a file from /usr/share/zoneinfo/ to /etc. In my case “/usr/share/zoneinfo/Europe/Berlin“ and “/etc/localtime” are identical.

Timezones on Linux are apparently a mess. We have 4 different systems.
/etc/localtime is done by resolving the symlink path.

    // Check TZ env var first, if not populated try find it
    QByteArray ianaId = qgetenv("TZ");
    if (!ianaId.isEmpty() && ianaId.at(0) == ':')
        ianaId = ianaId.mid(1);

    // On Debian Etch and later /etc/localtime is real file with name held in /etc/timezone
    if (ianaId.isEmpty()) {
        QFile tzif(QStringLiteral("/etc/timezone"));
        if (tzif.open(QIODevice::ReadOnly)) {
            // TODO QTextStream inefficient, replace later
            QTextStream ts(&tzif);
            if (!ts.atEnd())
                ianaId = ts.readLine().toUtf8();
        }
    }

    // On other distros /etc/localtime is symlink to real file so can extract name from the path
    if (ianaId.isEmpty()) {
        const QString path = QFile::symLinkTarget(QStringLiteral("/etc/localtime"));
        if (!path.isEmpty()) {
            // /etc/localtime is a symlink to the current TZ file, so extract from path
            int index = path.indexOf(QLatin1String("/zoneinfo/")) + 10;
            ianaId = path.mid(index).toUtf8();
        }
    }

    // On some Red Hat distros /etc/localtime is real file with name held in /etc/sysconfig/clock
    // in a line like ZONE="Europe/Oslo" or TIMEZONE="Europe/Oslo"
    if (ianaId.isEmpty()) {
        QFile tzif(QStringLiteral("/etc/sysconfig/clock"));
        if (tzif.open(QIODevice::ReadOnly)) {
            // TODO QTextStream inefficient, replace later
            QTextStream ts(&tzif);
            QString line;
            while (ianaId.isEmpty() && !ts.atEnd() && ts.status() == QTextStream::Ok) {
                line = ts.readLine();
                if (line.startsWith(QLatin1String("ZONE="))) {
                    ianaId = line.mid(6, line.size() - 7).toUtf8();
                } else if (line.startsWith(QLatin1String("TIMEZONE="))) {
                    ianaId = line.mid(10, line.size() - 11).toUtf8();
                }
            }
        }
    }

could you set the date with timedatectl?

Finally, do you have the env var TZ set? is there a /etc/timezone?

Yes, I can query and set the timezone with timedatectl. It does not help to do so.
Yes, there is a /etc/timezone and it contains „Europe/Berlin“
TZ is unset. If I set TZ to “CET” the digital clock works.

I was wrong.
On Debian TZ is set to “:/etc/localtime”, this makes the clock fail.
Unsetting TZ makes the clock work, at least if startet with plasmawindowed
  TZ=   plasmawindowed /usr/share/plasma/plasmoids/org.kde.plasma.digitalclock/
does work.

> On Debian TZ is set to “:/etc/localtime”, this makes the clock fail.

That Qt code is clearly wrong. According to the glibc docs[1], ":/something/something" should be read as a path, not a timezone. The code however assumes it's the IANA ID, which then results in invalid timezone.

I'll see if I can get it fixed in Qt.

[1] http://www.gnu.org/software/libc/manual/html_node/TZ-Variable.html

Qt patch at https://codereview.qt-project.org/#/c/143091/

Fix in Qt 5.6 [1].

You might want to notify Debian Qt maintainers to backport this patch to their current package.

[1] - http://code.qt.io/cgit/qt/qtbase.git/commit/?id=891c98ebd63b5a5b079a1f5a2736a29d89afcbd2

① The patch does not solve the problem, it is a workaround, because a correctly set TZ-Variable gets ignored if it uses the “:”-syntax.

② digital-clock should fail more gracefully if it can not determine the timezone. At the moment the plasmoid gets totaly unusabel, even setting a timezone manually in the settings does not bring the display back.

...you're welcome.

> ① The patch does not solve the problem, it is a workaround, because a correctly set TZ-Variable gets ignored if it uses the “:”-syntax.

No.

>    QByteArray ianaId = qgetenv("TZ");
>    if (!ianaId.isEmpty() && ianaId.at(0) == ':')
>        ianaId = ianaId.mid(1);

If you set TZ=":Europe/Berlin", it will correctly return "Europe/Berlin".
The patch will ignore TZ=":/etc/localtime" because the timezone name
will get read from /etc/timezone (which is what should be happening).

It will not work if you put an absolute path into your TZ env var. Which is
not what any guide/manual encourages you to do so, so, honestly, I'd close
such bugreport as invalid. There are 4 other ways to read a system timezone,
just use one of those.

Feel free to submit another patch reading an absolute path correctly however.

> ② digital-clock should fail more gracefully

Yes.

How about:

  time_t tt = time(0);
  struct tm *tm = localtime(&tt);
  char tz[20];
  strftime(tz, 19, "%Z", tm);
  QByteArray ianaId(tz);

I'd suggest following through with this: https://wiki.qt.io/Qt_Contribution_Guidelines