The error seems to be risen because use_ntp is set in dbus api... i will check it better.

concerning timezone I have to check why as well.

Adding Colin to get feed backs from dbus in the case we need

CC: (none) => mageia

some more information into bug #15534

as far as i can say America/Sao_Paulo can be set in manaclock
[anaselli@localhost ~]$ date
lun 23 mar 2015, 05.11.54, BRT
[anaselli@localhost ~]$ ll /etc/localtime 
lrwxrwxrwx 1 root root 39 mar 23 05:11 /etc/localtime -> ../usr/share/zoneinfo/America/Sao_Paulo

I will investigate without ntp set now.

@Renato could you please post the output of next command?

gdbus introspect --system --dest org.freedesktop.timedate1 --object-path /org/freedesktop/timedate1

Here it is:

[zz@localhost ~]$ gdbus introspect --system --dest org.freedesktop.timedate1 --object-path /org/freedesktop/timedate1
node /org/freedesktop/timedate1 {
  interface org.freedesktop.DBus.Peer {
    methods:
      Ping();
      GetMachineId(out s machine_uuid);
    signals:
    properties:
  };
  interface org.freedesktop.DBus.Introspectable {
    methods:
      Introspect(out s data);
    signals:
    properties:
  };
  interface org.freedesktop.DBus.Properties {
    methods:
      Get(in  s interface,
          in  s property,
          out v value);
      GetAll(in  s interface,
             out a{sv} properties);
      Set(in  s interface,
          in  s property,
          in  v value);
    signals:
      PropertiesChanged(s interface,
                        a{sv} changed_properties,
                        as invalidated_properties);
    properties:
  };
  interface org.freedesktop.timedate1 {
    methods:
      SetTime(in  x arg_0,
              in  b arg_1,
              in  b arg_2);
      SetTimezone(in  s arg_0,
                  in  b arg_1);
      SetLocalRTC(in  b arg_0,
                  in  b arg_1,
                  in  b arg_2);
      SetNTP(in  b arg_0,
             in  b arg_1);
    signals:
    properties:
      readonly s Timezone = 'America/Sao_Paulo';
      readonly b LocalRTC = false;
      @org.freedesktop.DBus.Property.EmitsChangedSignal("false")
      readonly b CanNTP = true;
      readonly b NTP = true;
      @org.freedesktop.DBus.Property.EmitsChangedSignal("false")
      readonly b NTPSynchronized = true;
      @org.freedesktop.DBus.Property.EmitsChangedSignal("false")
      readonly t TimeUSec = 1427115709500735;
      @org.freedesktop.DBus.Property.EmitsChangedSignal("false")
      readonly t RTCTimeUSec = 1427115709000000;
  };
};
[zz@localhost ~]$

I also confirm the same linking you posted in comment 3, Angelo.

Created attachment 6126 [details]
Error changing timezone in adminpanel-qt.

Created attachment 6127 [details]
Digital clock widget conflicting times.

Yes I know the error is always there and the reason is that 
the property NTP is true as you posted in comment#5 :D

I could avoid that bu i'd like to understand why it is...

Do you have any ntp service configured? (ntp or chrony)
and if which is its status by using 
systemctl status followed by ntpd.service or chronyd.service?

And in any case which is the output of
systemctl status systemd-timesyncd.service ?

thanks.

Hi, Angelo,

I don't remember configuring NTP, but maybe that is the default in installation. The last time I didn't even check the last screen with all options about keyboard, network, screen resolution. I just pressed Next to get Mageia 5 RC3 installed (I had installed it some 4 or 5 times because of another serious bug and it takes about 2 hours in this machine).

If I ever heard about chrony (doubtful), I'm sure I didn't opt for it.

Here goes the statuses:

[zz@localhost ~]$ systemctl status ntpd.service
â ntpd.service
   Loaded: not-found (Reason: No such file or directory)
   Active: inactive (dead)
[zz@localhost ~]$

[zz@localhost ~]$ systemctl status chronyd.service
â chronyd.service
   Loaded: not-found (Reason: No such file or directory)
   Active: inactive (dead)
[zz@localhost ~]$

[zz@localhost ~]$ systemctl status systemd-timesyncd.service
â systemd-timesyncd.service - Network Time Synchronization
   Loaded: loaded (/usr/lib/systemd/system/systemd-timesyncd.service; enabled)
   Active: active (running) since Seg 2015-03-23 14:57:56 EAT; 1h 55min ago
     Docs: man:systemd-timesyncd.service(8)
 Main PID: 535 (systemd-timesyn)
   Status: "Using Time Server 216.239.32.15:123 (time1.google.com)."
   CGroup: /system.slice/systemd-timesyncd.service
           ââ535 /usr/lib/systemd/systemd-timesyncd
[zz@localhost ~]$

This is a test installation -- because it's a beta. I'm sure I wouldn't bother to configure time syncing *now*, so it reinforces my notion I didn't ask for that. Maybe it's a default in Mageia; in that case, it could have implications for people who are security/privacy-conscious.

For documentation purposes, I tested adminpanel-qt a little more and I noticed that:

To test adminpanel-qt, I opened it (Menu / Tools / System Tools / Mageia AdminPanel), once in it selected System / Setting Date and Time and changed the time zone to America / Rio Branco.

As a result, nothing apparently happened (I didn't press ok).

Pressing Ok resulted in an error (pic attached).

Checking /etc, I got:

[zz@localhost ~]$ ll /etc/localtime 
lrwxrwxrwx 1 root root 37 Mar 23 01:06 /etc/localtime -> /usr/share/zoneinfo/America/Sao_Paulo
[zz@localhost ~]$ 

That shows the timezone wasn't changed. In the picture, one can see two São Paulo time zones with different times. One actually is Rio Branco's.

Further testing with adminpanel-qt revealed that:

- upon pressing ok, the aforementioned error occurs immediately
- despite said error, the timezone is altered as the following ll command shows:

[zz@localhost ~]$ ll /etc/localtime 
lrwxrwxrwx 1 root root 40 Mar 23 16:34 /etc/localtime -> ../usr/share/zoneinfo/Africa/Addis_Ababa
[zz@localhost ~]$

Hovering the mouse on the panel's digital clock widget, we get two times:
- São Paulo (configured to show in the widget) with the correct time
- Addis_Ababa time as localtime, correctly displayed, but labeled as "Rio Branco"!

The plot thickens... :-)

Regarding the panel's digital clock widget behavior:

When changing timezone (*), the time changes after some 2 to 5 seconds.

The timezone label does not change (is not updated) until the KDE session is restarted.

(*) Drakclock and adminpanel-qt can change time zone, though the latter displays an error dialog; KDE Systemsettings cannot change the time zone.

None of the three can change the time, possibly due to time syncing.

Yep, all went as you said :)

Some explanation when i decide to move manaclock to dbus i also decide to
set things when ok button is pressed, so that cancel would have changed nothing. 
But i didn't make comparison with the old status so, from user POW three
times password is required. NTP (start stop ntp service from systemctl api)
set time, and set TZ. I will better implement this part to:
1) avoid setting time when NTP is active
2) managing also systemd-timesyncd.service that is running on your system as you showed in comment #9
3) looking if i can set things only when really changed to avoid useless password
asked.

The error you saw -documented by the first attachment in description- is due to the fact that (systemd) ntp is really enabled and running. (in my system
was just enabled but dead because i use chronyd) so disabling it allows to
set you date and time freely.
To have the proof you can run without touching anything:
timedatectl set-time <TIME>
and you should read the same error as in manaclock.

And finally the different TZ, the right one is the one you configured with 
manaclock as the link in comment #9 showed.
Drakclock still shows the one it has into /etc/sysconfig/clock if you change by hands another ZONE=blah/blah there you can read new "fake" settings, until you
don't save it by changing using drakclock.

You can disable systemd timesync by giving:
timedatectl set-ntp 0
as into systemd (timedated) documentation.
Then i'd like to understand which servers is using by default (google ones?)

> Some explanation when i decide to move manaclock to dbus i also decide to
set things when ok button is pressed, so that cancel would have changed nothing.

Pretty wise, IMHO. This kind of thinking is one of the reasons (also IMHO) for KDE being light-years ahead of Gnome (and Xfce) in usability. It surely seems practical to have instant change after user interaction, but in certain occasions -- like when changing options in the Advanced tab of KDE's Desktop effects -- one has to change 2 or 3 settings at once (e.g. Xrender+Native to OpenGL 1.2+Rasterized). Changing immediately just one option won't do.

The use of an apply button also gives the user some time to think about what he's doing. For example, I set my video resolution to 700x400 in Systemsettings new module to configure the monitor. Alas, it flunked. The screen became garbled and didn't work anymore -- in that case, the previous mode should be restored if the new settings were not confirmed (I probably should open a bug about that, but that's outside Mageia's scope -- something to be reported directly to KDE, for sure). Why such resolution was considered valid and then doesn't work? That, I don't know.

About item 3:

> 3) looking if i can set things only when really changed to avoid useless password asked.

... I should say that MCC was activated using the PC root password (it asks for it every time), so it's supposed to have root authority all the time as I understand. Is it not so?

> To have the proof you can run without touching anything: timedatectl set-time <TIME>

Indeed, it answered "Failed to set time: automatic time sync is enabled".

> Then I'd like to understand which servers is using by default (google ones?)

Yes, as can be seen in comment #9: "time1.google.com". I wonder if one should use a more neutral one, like from an observatory or something. Then again, this might have security implications. One might need to use a local time server due to mandated policies, for example. Systemd defaulting to google is something to be evaluated, me thinks. I personally use their DNSes, so I'm not against it, but some people at some organizations cannot even exercise their personal opinion: e.g. this might be the subject of a security directive.

This might impact the installation procedure, as well.

I'm ok with systemd -- I even think it works rather well for its (new) age --, but it's comprehensible why server people get annoyed at such things.

Thanks for your work in dealing with this time problem. I even think some good insights will be possible about the areas on which MCC and KDE's Systemsettings overlap.

> ... I should say that MCC was activated using the PC root password (it asks
> for it every time), so it's supposed to have root authority all the time as
> I understand. Is it not so?
and manaclock is as well -and adminpanel/manatools too-, if launched from
menu or by using pkexec, since some dbus api allow to be run as user and then
prompt for password we decided to left this opportunity also.

> Yes, as can be seen in comment #9: "time1.google.com". I wonder if one
> should use a more neutral one, like from an observatory or something. Then
> again, this might have security implications. One might need to use a local
> time server due to mandated policies, for example. Systemd defaulting to
> google is something to be evaluated, me thinks. I personally use their
> DNSes, so I'm not against it, but some people at some organizations cannot
> even exercise their personal opinion: e.g. this might be the subject of a
> security directive.
there is a configuration file to change for that run man systemd-timesyncd.service for that, I'm in mga4 here and i don't have it :)
 
> This might impact the installation procedure, as well.
well darkx is deputed to it now, we'll see in future.
 
> Thanks for your work in dealing with this time problem. I even think some
Oh... but i will fix it -at least in manaclock- :)

Hehe, sorry, I tend to digress a lot.

I'm happy that you all are doing some kind of reorganization of Mageia configuration tools. I find particularly troubling the integration of other toolkits with KDE -- I recall a recent problem in Firefox forced me to change the gtk theme to Adwaita instead of Oxygen-gtk (can't exactly remember now what it was, but the mentioned change solved the problem).

Maybe you could exchange some tricks with guys from Mint as they are doing similar things -- as I've read about it on this link:

http://arstechnica.com/gadgets/2014/06/mint-17-the-perfect-place-for-linux-ers-to-wait-out-ubuntu-uncertainty/

commit a664f924402976b32f30310430d08393f254c2ce
Author: Angelo Naselli <anaselli@...>
Date:   Wed Mar 25 23:09:12 2015 +0100

    Manage new data from backend, partially fixed mga#15552
---
 Commit Link:
   http://gitweb.mageia.org/software/adminpanel/commit/?id=a664f924402976b32f30310430d08393f254c2ce

Hi, Angelo,

I was trying to make KDE lighter (on my Mageia 4 PC) and realized there is a KDE time zone service. According to description, it provides the system time zone to applications.

I then suspect there should be no need to restart the KDE session to change the label/name of the time zone. Maybe this has some relation to the dbus problem.

Sorry if you already knew that, I don't mean to offend, I just thought it might help.

Thanks.

@Renato take it easy :) All it's ok. The delay in updating data into DE is quite normal, and take some seconds usually.

I have to fix something I'm not convinced yet and i hopefully release a new version.

The package name could change though, since we now decided to call manatools instead adminpanel. The good is that you can run qt, gtk and ncurses application
with just one application written, the bad is that I'm not so good in designing
application layout... so sometimes it could be done with more love :)

.... stay tuned :)

> @Renato take it easy :)

Hehehe. The world was built in seven days because there was no one pestering by asking "is it ready yet?" 8-)

IIRC, Mageia 4 expires in August -- and even then its support could be kept for some time more, I believe. And Mageia 5 seems already quite usable; a few weird things, but otherwise things are mostly ok.

Manatools sounds better (but adminpanel was good, too, IMHO).

All in all, Mageia people are doing a great job. Thank you and please let them know I appreciate this awesome distribution.

(In reply to Angelo Naselli from comment #11)
 
> You can disable systemd timesync by giving:
> timedatectl set-ntp 0
> as into systemd (timedated) documentation.
> Then i'd like to understand which servers is using by default (google ones?)

cat /etc/systemd/timesyncd.conf

I do hope your code supports changing system time when there is a different time server running than timesyncd.

CC: (none) => junknospam

on comment #19, our code... ;)

our code is taken from drakclock, so supports ntpd and chronyd, Now it supports
also timesyncd, that is installed by default and usually active even if you 
have not installed any ntp service yet.
Hope this was the right answer to your question.

(In reply to Angelo Naselli from comment #20)
> on comment #19, our code... ;)
> 
> our code is taken from drakclock, so supports ntpd and chronyd, Now it
> supports
> also timesyncd, that is installed by default and usually active even if you 
> have not installed any ntp service yet.

Yeah, I know. I run "journalctl -fa --no-pager" in an xterm and was seeing time sync and hardware sync messages about every 10 minutes. I don't need that kind of noise in the journal so I disabled timesyncd.


> Hope this was the right answer to your question.

Thanks, and I hope the cat /etc/systemd/timesyncd.conf answered your google  ones?

Now you can disable it also by using manaclock :)

/etc/systemd/timesyncd.conf is empty or at least commented... but default
fallback NTP are google ones though...

manatools is now obsoleting adminpanel and version 1.0.1 has been released and
should fixed this problem.

Status: ASSIGNED => RESOLVED
Resolution: (none) => FIXED

Thanks, Angelo!