Looks like this is the cli way:

qdbus --system org.freedesktop.timedate1 /org/freedesktop/timedate1 \
   org.freedesktop.timedate1.SetNTP 1 1

shouldn't be too hard to hook into that in the code.

Oh, and see also bug #816752 "systemd v28 changes indirectly break date and ntpdate"

The right way to handle this would be using QtDBus, not spawning qdbus through KProcess or QProcess. Also, the KDE-specific KAuth mechanism for kcm_clock should then go away entirely, because systemd already handles the PolicyKit stuff. Basically all the backend code of kcm_clock can be thrown away in favor of systemd's implementation.

This is also somewhat related to bug #829881 because we'd be using the org.freedesktop.timedate1.* policies instead of the org.kde.kcontrol.kcmclock.save one (assuming we implement this correctly – again, just spawning qdbus as root instead of ntpdate in the existing kcm_clock mechanism is NOT the correct way, the point of the systemd service is that it handles everything including the polkit stuff).

Aye, let's see :)

So, after having the prototype code ready and working, I, however, decided not to go this way for several reasons:

1. the current KAuth code works fine and we'd have to keep it anyway, either for compatibility reasons or for people who decide to disable systemd-timedated which would result in code bloat, not reduction
2. systemd-timedated doesn't correctly read the timezone back, if you set it by the traditional means (like using date(1) or tzset(3))
3. systemd-timedated has distinct methods for changing datetime, timezone and ntp preference, however, each of these methods invokes polkit in the background, resulting in 3 (!) auth dialogs presented to the user in consecution when confirming the KDE date/time control dialog
4. systemd-timedated lacks a signal telling us the date/time/timezone have been indeed changed