On Sat, 2014-06-07 at 18:34 +0200, Ralf Mardorf wrote: > On Sat, 2014-06-07 at 11:14 -0500, Doug Newgard wrote: > > On 2014-06-07 11:05, Ralf Mardorf wrote: > > > On Sat, 2014-06-07 at 17:54 +0200, Bardur Arantsson wrote: > > >> On 2014-06-07 17:46, Ralf Mardorf wrote: > > >> [--snip--] > > >> > > > >> > I suspect it's just the evil policy of those systemd folks, who want to > > >> > teach everybody to follow there ways, as the only right ways. > > >> > > > >> > > >> Please don't insinuate conspiracies without good evidence. > > > > > > It's not a bug, nothing needs to be fixed [1]. So what is the reason > > > for > > > this decision, when it's not a bug? It worked with _all_ systemd > > > versions until now, it still works with sysvinit and upstart. It > > > _never_ > > > cause trouble to use localtime the last 11 years on my machines, just > > > the current systemd upgrade for my Arch Linux, for the first time ever > > > in 11 years does cause trouble. > > > > It's not a bug because using a time that warps forward and backward as > > your internal yardstick is simply not sane. The bug linked to above > > happened because nobody tested systemd with a RTC in localtime. That's > > not surprising, since people who actually know what's happening behind > > the scenes know that using localtime makes no sense and wouldn't run it. > > > > And nobody cares that you've been using Linux for 11 years. Really, get > > off of it. (I say this as a Linux user of > 15 years.) > > There was a choice until now, at least for the last 11 years, perhaps > longer and now there's no choice anymore. Using UTC has got advantages, > but for some needs localtime is the better choice, so why not providing > a choice anymore? PS: Perhaps the time when backing up a BIOS any way is encoded in UTC, but at least I can see the correct time when using the BIOS (when taking a look at the BIOS time) or when experimenting with the hardware, without using an OS. However, I will close this thread, a discussion it will lead to nothing.