On Tue, Mar 24, 2015 at 3:17 PM, Stef Walter <[email protected]> wrote: > On 24.03.2015 15:11, Kay Sievers wrote: >> On Tue, Mar 24, 2015 at 2:15 PM, Zbigniew Jędrzejewski-Szmek >> <[email protected]> wrote: >>> Exactly because they do not require being upgraded in lock-step, doing >>> conversion to the local time locally is "racy". Assuming we have up-to-date >>> timezone database locally, with the patch that was merged today we can >>> answer the question "what the local time should be remotely", but not >>> necessarily "what the local time is remotely". >>> >>> If we go to the trouble of displaying the remote local time, imho we >>> should do it as the remote does. >> >> No, we should care about the *state* of the system, and that is its >> time value and its configured location on earth. > > Then stop displaying incorrect "presentation" data in timedatectl.
Isn't it fixed with Shawn patch? >> Systemd has no business in "fixing" the *presentation* logic of these >> values. It is not an API for the timezone database. These tools >> already exist. >> >> Please stop trying to add insufficient and half-thought-through APIs >> to cover problems which just do not exist in reality or do not need to >> be worked-around by systemd. > > This gives us what we need: > > $ date '+%s:%:z' > > So we'll use that instead of timedated. I'll update the wiki page for > the timedated DBus interface to note parts of it are just not remotable. Which parts are not not-remotable? You get the exact values you need for a machine, it's current time and location. Kay _______________________________________________ systemd-devel mailing list [email protected] http://lists.freedesktop.org/mailman/listinfo/systemd-devel
