On 04/28/2016 10:27 AM, Zhanibek Adilbekov wrote:

formats of zones are changed, e.g. for Asia/Almaty it changed from ALMT to +06. I'm not familiar with TZ files, but I suppose this changes are the reason of incompatibility for some apps.

Yes, I think that's relevant to the Plasma Digital Clock bug. I found what appears to be a related bug in the way that Qt handles data from tz 2016b, so the problem is not limited to tz 2016d. I can reproduce the problem by using just the Qt base, without involving KDE or Plasma. The Qt base parses tz data directly (!), and appears to do so incorrectly. I have filed a Qt bug report here: https://bugreports.qt.io/browse/QTBUG-53071 zic.c already has workarounds for buggy programs that misparse tzdata files containing time stamps far in the past, by putting in a no-change transition before the Big Bang. Perhaps there could be a similar workaround for this Qt bug, as Qt appears to mishandle tzdata files where the predicted future uses a POSIX TZ string that assumes POSIX.1-2001 or later. That is, perhaps we can work around the Qt bug by appending to the binary data some sort of no-change transition far enough in the future that we can expect Qt to be fixed in the field before most users care about those future time stamps. The year 2116, say?