Thanks David! Yes, I missed Lennart's reply.
Thanks Lennart!
Yes, I agree rtc-in-local-time is a compatibility hack.
But I think similar issues in other components is orthogonal to this
bug. The key is that systemd records _inconsistent_ timestamps. It's
surely a logic _error_ introduced in commit
3a170f3d3358135a39ac6eafe66f18aef0bd67d, even though this bug appears in
"compatibility hack".
rtc-in-utc is orthogonal too. In contrast, using rtc-in-utc is a
workaround in this situation. Since we provide the compatibility, we
have to fix it.
Best Regards,
Chunhui He
On 12/23/2014 09:28 PM, David Herrmann wrote:
Hi
On Thu, Dec 18, 2014 at 3:33 PM, Chunhui He <hchun...@mail.ustc.edu.cn> wrote:
Hi all,
When the system is configured to read the RTC time in the local time zone,
some timestamps recorded by systemd are wrong.
Apparently, you never received Lennart's reply on your original mail.
Below, you can find his original comment.
Thanks
David
Quoting Lennart:
----------------
I am not really convinced that we really should try to make this
work. rtc-in-local-time has so many issues, it really doesn't stop
here. If people make use of this, then this is what they get really,
and I am not sure we really should work around it. I mean, systemd
really isn't the only component which might query the clock this
early, in the initrd there might be a ton of other components too, and
it's not realistic to add similar kludges to them all.
In general: rtc-in-local-time is a compatibility hack, and we only
want to support it to the minimal level necessary for compatibility,
but not more. The proper fix for this problem I guess is to use
rtc-in-utc instead!
Sorry if that's disappointing,
Lennart
_______________________________________________
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel
