<div dir="ltr">On Wed, Jun 5, 2013 at 12:34 AM, Steve Riley <span dir="ltr"><<a href="mailto:steve@rileyz.net" target="_blank">steve@rileyz.net</a>></span> wrote:<br><div class="gmail_extra"><div class="gmail_quote">

<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">It's probably one of the symptoms of <a href="https://bugs.launchpad.net/ubuntu/+source/kde-workspace/+bug/1168578" target="_blank">https://bugs.launchpad.net/ubuntu/+source/kde-workspace/+bug/1168578</a>. But it appears to be something upstream instead, see <a href="https://bugs.kde.org/show_bug.cgi?id=318709" target="_blank">https://bugs.kde.org/show_bug.cgi?id=318709</a><br>


<br>
On the forum, we first saw this in the middle of March. In experimenting with the time zone settings, I managed to make mine malfunction -- UTC and America/Los_Angeles became the same. Reconfiguring tzdata fixed it, see <a href="http://www.kubuntuforums.net/showthread.php?62171#post324366" target="_blank">http://www.kubuntuforums.net/showthread.php?62171#post324366</a>.<br>

</blockquote><div><br></div><div style>actually it's more complicated and apparently I underestimated the impact....</div><div style><br></div><div style>the datetime kcm as I recently noticed uses a commandline tool called zic to set the timezone. zic however does not work on debian systems in fact it renders the timezone setup (i.e. the timezone related files in /etc) broken which supposedly leads to the clock then always defaulting to the hardware clock. iff the hardware clock is equal to the actual timezone time (as is the case on systems that also have windows for example) you'd not notice except for the fact that you cannot change the timezone in general, if the clock is UTC however you always get UTC (meh).</div>

<div style><br></div><div style>whether that is what Aleix highlighted is not clear though. in particular it seems curious that it would break on upgrade as you'd need to manually run the kcm and set a different timezone to break the configs. the only possible explanation is that the configure script of tzdata got confused by broken configs and then tried to fix it but failed and introduced a timezone value that resulted in a bogus end result (why yes, that does not only sound confusing, it really is...). so, I am not really sure that is the issue here but it can very well be.</div>

<div style><br></div><div style>making matters worse, reconfiguring tzdata actually forces whatever the user configures, removing and overwriting whatever was broken.</div><div style><br></div><div style>without a system that has broken timezones after an uprade but did not get fixed yet it is nigh impossible to find out whether the KCM/zic are at fault or something else is going terribly wrong.</div>

<div style><br></div><div style>fixing it automagically would be a bit tricky but probably possible. but that is not much of a fix until the KCM is also fixed as the user can still break it.</div><div style><br></div><div style>

HS</div></div></div></div>