On 04/29/2015 11:14 AM, Lennart Poettering wrote:

On Wed, 29.04.15 16:46, Lubomir Rintel (lkundrak@v3.sk) wrote:

On Wed, 2015-04-29 at 14:00 +0200, Ralf Corsepius wrote:

On 04/28/2015 03:52 PM, Lennart Poettering wrote:

And no, this *never* worked fully on Linux, and it never will, 
sorry.

But it worked sufficentily most of the time ... ever since!

The current situation means,
- Fedora does not support multiboot'ing at all,
- Fedora is preferring to be militant against Windows
- Fedora is hostile and ignorant against its users.

It seems to be that either way this gets solved it leaves unhappy
users and developers behind. Given the scope of the issue is wider
than just a package maintenance issue, I'm wondering if FESCO could
help getting it settled?

Would it make sense to create a FESCO ticket and let it vote on the
matter? (Work around in Fedora vs. hardcode UTC and encourage the fix
in Windows NT?)

Hmmm?

This is unfixable, FESCO can decide what it wants. You cannot fix RTC
management, since you cannot change Windows...

I agree that it's not possible to make this work under every circumstance, but a compromise existed that worked well enough so that most people were not complaining. I propose that a system that possibly hiccups every year or two is better than a system that misbehaves all the time. Why can't the startup just treat the RTC as if it was GMT with an unexplained offset? e.g. measure that offset when time syncing with reliable sources, write it down and use it on the next boot?

By the way, it'd be nice if the startup dealt gracefully with all kinds of clock problems. Many embedded systems have no persistent realtime clock at all; I seem to remember that Beaglebone uses a hack that initializes clock from a fixed value from a file.