Thank for your post.

New code, see why here:
http://slashdot.org/comments.p...
http://slashdot.org/comments.p...

Please provides some reference to back your claims.

systemd-timesyncd goal is to provides a very simple NTP client to very simple systems like diskless machines or tiny embedded systems. The fact is that having a system time set to something close to the actual time is a desirable feature, not only to get log with usable timestamp, but also for some security protocols.

You are right. Maybe the list should be GMST, GAST, LMST, LST ? Taken from "Astronomical Times" page here: http://www.cv.nrao.edu/~rfishe...

systemd-timesyncd is a completely independent an optional application. His 'systemd' prefix only exists because his code is part of the systemd repository and because it use the libsystemd interface. See by yourself: https://github.com/systemd/sys...

It do exactly what you expect: it is not part of the systemd initialization code, but work with systemd interface library like any applications that want to work with this new interface. See for example this situation on a custom ARM board running Debian jessie:

root 1 0.0 0.5 4364 3008 ? Ss Mar12 0:04 /sbin/init
root 605 0.0 0.4 7360 2472 ? Ss Mar12 0:03 /lib/systemd/systemd-journald
root 909 0.0 0.4 9964 2268 ? Ss Mar12 0:00 /lib/systemd/systemd-udevd
systemd+ 924 0.0 0.3 12104 1564 ? Ssl Mar12 0:00 /lib/systemd/systemd-timesyncd

Please verify some basic information before making critic to systemd-timesyncd, because from what I understand it is designed precisely the way you recommend.

Why ? The purpose of systemd-timesyncd is to provides a simple time synchronization client for diskless machines (without /etc folder). It's a completely optional application that will not replace a real NTP server.

Aside of the systemd purely emotional polemic, having a full NTP service into the systemd repository will at least make it potentially in a position to get some more care from a larger set of developers than in the actual situation of the venerable ntpd.

Fully agree.

Technically all GPS receiver have internally a clock signal that could relatively easily generate a PPS signal, if not already the case. But not all receivers don't expose this signal to a user available pin.

The real types that matter to computers are:

(1) TAI: Don't depend on the Earth rotation or on the position on the Earth surface. The only time safe to compute any past and future time as log as you have enough bits to store the number.

(2) UTC: Depend on Earth rotation but don't depend on the position on the Earth surface. Require the leap second table to safely compute some past time. Unsafe to compute future time because of the Earth rotation instability that make future leap second unpredictable.

(3) Local time: Depend on the Earth rotation and on the position on the Earth surface (and local government decision). Require leap second table and timezone database to compute some past local time locally on the Earth surface. Unsafe to compute future time because of the Earth rotation instability and future timezone changes impossible to forecast.

Astronomers more likely uses one of UT, UT0, UT1, UT1R, UT1D, or UT2: something that is more bond to the real physical angular rotation of the Earth.

It would be a giant step forward if NTP will be able to broadcast TAI, the leap second table, and the timezone database.

The leap second table and the timezone database are dynamic informations that need to be updated at least 2 times per years. You can arg that this can be done using the operating system upgrade, but the reality is that many machines will not be updated for whatever bad reasons. So carrying the informations using NTP (or PTP or GPS for that matter) will be an clear advantage.

GPS signal availability can depend on bad local whether condition.

systemd-timesyncd
http://www.freedesktop.org/sof...
It's only the client side of NTP, but enough for diskless machines it is designed for.

Already done for the client part of the NTP: systemd-timesyncd

While each of those protocols have some advantages depending on the network availability, there all need to be upgraded to bring all the features required to make almost every applications happy.
* NTP need to broadcast TAI time, leap second table and timezone database.
* PTP need to broadcast lead second table, and timezone database.
* GPS need to broadcast at least the leap second table (serialized into a few bits over a long period), timezone database will probably be too big.

The TAI time is required to every strict realtime applications that don't rely on the Earth rotation. This is the only time where you can safely add and subtract time and get a precise result in any cases.
The Leap second table is required to every applications that depend on the Earth rotation, like for example the UTC time. Without the leap second table you can't precisely compute past time across leap second inclusion. But remember that even with the leap second table you can NEVER precisely compute future time across possible future leap second inclusion because the Earth rotation is unstable and the decision to include a new leap second is done on a 6 months basis.
The timezone database (and the leap second table) is required to every applications that need to manage local time depending on the location on the Earth surface. Without up to date timezone database, you can't precisely compute the local time of a past event. Because future time rely on future leap second inclusion, you can NEVER precisely compute future local time across possible leap second inclusion.

The nirvana would be that most concerned standardization organizations (ITU, ISO, IEEE, POSIX, etc...) and scientists agree to write a reference library to solve all the time computation, exchange, and broadcasting problem. Almost every libraries and languages are incomplete or compute imprecise result without warning.

As for the leap second abandon, it's a false problem: the reality is that the Earth rotation is unstable and that life activity on Earth deeply depend on the Sun light. A post-correction system will always be required. Mixing it with the timezone offset is a very bad option that will even more confuse the already hard problem of the timezone across the whole Earth surface. But it would be an advantage to make the leap second table available from the timezone database.

I now wonder if it's a good idea to add ACPI to the ARM architecture. The device tree have the advantage to be far simpler and more robust since it can't change depending on the operating system loaded.

Low-end SoC market is already full of competitors. A new ugly chip (external design with Intel label, and no previous base) is unlikely to change anything. The bad Intel records into the SoC market don't help either.