Bug 114902

The "detection" is done by checking if user have primary windows partition -
actually it is not detection, but a guess, because with a windows, one can
assume your system runs local time.

I don't think we can do much about this.

I can't quite accept that. My clocks run on UTC, I have a primary fatXX 
partition (for those obnoxious firmware updaters). On a new install, I select 
timezone Global/NZ and change clock to "UTC" in yast. The time now displayed 
is ***local time for Global/NZ***. 
 
Ok, the issue is not how you detect whether the time in CMOS is local or UTC, 
the issue is that the "UTC"/"local" selector (bottom center) doesn't match the 
time displayed right next to it. I expect the time to always be displayed in 
the selected time zone, i.e. local. If I am in UTC+12h, local time is 15:00, 
yast shows time as 15:00, and I select "CMOS on UTC", I expect 3:00 to be 
written into the CMOS. This is not the case. On next boot, local time is 3:00 
when it should be 15:00. i.e. you're 12h behind. 
 
If you're arguing (I hope you don't) that when selecting "CMOS on UTC" the 
time displayed is in UTC, on next boot you ought to be 12h *ahead*! However I 
look at it, it's a pain and a half. 
 
Someone else on suse-beta-e noted the annoyance of this recently, ie during 
10.0 beta. I am reopening because I say it's a bug in the way the entered and 
displayed time in yast is handled. When I enter 15:00 in yast, on next boot I 
expect local time to be 15:00. This is independent on whether I want UTC or 
local in CMOS. I don't much care whether you read the CMOS as UTC or local for 
the first time (I agree your "heuristics" are as good as it might get), I care 
that you write back in what I say ;) 
 
Is this clearer now? My summary line for this bug was/is misleading, sorry. 

Your're right, the time shown should be written; I'm not sure why it wasn't.
Please attach the log files from your installation:

http://www.opensuse.org/index.php/Bug_Reporting_FAQ#YaST

> Someone else on suse-beta-e noted the annoyance of this recently, ie during 
> 10.0 beta

Could you point me to that mail?

Created attachment 48719 [details]
yast logs

The mail I was remembering is 
 
From: "Ulrich Windl" <ulrich.windl@rz.uni-regensburg.de> 
To: suse-beta-e@suse.com 
Date: Mon, 29 Aug 2005 08:34:43 +0200 
Message-ID: <4312C8A2.9058.2B2072@rkdvmks1.ngate.uni-regensburg.de> 
 
sorry no list archive and therefore no URL, but he was only drawing attention 
to #104868. Esp see comment 18. 
 
Ulrich isn't saying whether to propose UTC or local has a bug (though there 
was also confusion about this issue), he's likewise pointing out that the 
input given to yast by the user isn't what finally ends up in the system. 

This is strange; last change from yast module was

/usr/sbin/zic -l NZ
/sbin/hwclock --hctosys -u

which resulted in correct 'date' output just next lines after it:

GetDateTime cmd=/bin/date "+%H:%M:%S - %d-%m-%Y"
GetDateTime local_date=13:39:56 - 02-09-2005

I assume that also in the proposal, the time was shown correctly:

"Global / NZ - Hardware Clock Set To UTC 13:41:01 - 02-09-2005\n"

No later time changes were done after this (only writing /etc/sysconfig/clock).

Thorsten, do you have any idea what's wrong?

I never looked at this.

And could you? You are the maintainer of 'timezone' package, that's why I'm asking.

Who handles updating the time accoring to timezone after start/reboot? Maybe
Rudi? (/etc/init.d/boot.clock is part of aaa_base)

Volker, please attach /etc/sysconfig/clock (I really think it is correct, but to
be sure...)

Sure. Comments stripped: 
 
HWCLOCK="-u" 
TIMEZONE="NZ" 
DEFAULT_TIMEZONE="US/Mountain" 
 
The file still has the time stamp of installation, so it didn't change. 
 
Btw if there is no M$ partition on SuLi 9.3, it seems the behavious is as I 
would expect: when changing the time zone to NZ, the displayed time jumps by 
quite a few hours, and then I set the time right again. From memory the system 
is then still correct after the next boot. 

> and then I set the time right again

Sorry? Why do you have to set the time? Changing timezone _only_ should be
sufficient.

One more think: on your system with wrong time, does it work to call

/usr/sbin/zic -l NZ
/sbin/hwclock --hctosys -u

on commandline? Is the time correctly changed? Does it stay after reboot?

[Note this comment referred to SuLi 9.3, not 10 beta. New install.] 
Why I have to set the time? Same reason as in #2: I expect the time displayed 
to be local and matching the time zone selected in the same yast window, 
*REGARDLESS* of whether I set "CMOS to UTC" or "CMOS to local". In yast, "UTC" 
was already selected (no billy partition), and the CMOS was running on UTC 
already (Linux previously installed). The time displayed by yast was correct, 
but the time zone was set to somewhere. When I changed the time zone to 
Global/NZ, the time displayed by yast changed by some hours, so I have to fix 
the time up again. Afterwards (first reboot at the latest), I 
expect /etc/localtime and the system's time to be correct. 
 
On 10.0 beta 4: 
/usr/sbin/zic -l NZ 
/sbin/hwclock --hctosys -u 
 
Produces correct result, time is: 
Tue 06 Sep 2005 11:35:51 UTC 
Tue 06 Sep 2005 23:35:51 NZST 
 
Time in CMOS would have been correct (and in utc), as the SuLi 9.2 normally 
running on this box has xntp going. 
 

I still do not understand your comments about that 9.3 situation; if you change
timezone and you are using UTC, time has to be changed.

About 10.0 beta behaviour: these exactly the commands yast used to set up your
time (btw, did you answered me if the time in installation proposal was shown
correctly? I mean that screen with partitioning, language, bootloader, timezone
etc.). So it does not look as YaST error.

I have tried to reproduce your situation:

I've faked my installation source so it suggested localtime to me although I
don't have any windows partition; so I have seen 13:05 as a time (result of
'date' after setting '/sbin/hwclock --hctosys --localtime') first time I entered
timezone dialog. That's correct, because 13:05 was UTC time, set in CMOS that time.

In timezone dialog, I switched to UTC and selected Europe/Prague: yast showed me
15:06:50, which was faked time in that time, calculated by 'TZ=Europe/Prague
/bin/date "+%H:%M:%S - %d-%m-%Y" "--date=now -21600sec"' command. And yes, this
was correct, Europe/Prague is one hour after UTC plus one hour for summer time
(CEST).

Then I clicked next, time was adapted using '/usr/sbin/zic -l Europe/Prague' and
'/sbin/hwclock --hctosys -u' commands -> then in proposal I could see again
"Europe / Czech Republic - Hardware Clock Set To UTC 15:07:59 - 06-09-2005"
which was now only get using '/bin/date "+%H:%M:%S - %d-%m-%Y"' - so the real
system time.

After installation, all remains correct: 15:44:25 at the end.