[tz] Issue in Time Zone Database for Kazakhstan's zones

[Paul Eggert]

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?