Re: Time quandry when dual boot with WinXP Pro

[Lisi Reisz]

On Saturday 29 October 2016 16:29:11 Felix Miata wrote:
> Lisi Reisz composed on 2016-10-29 15:44 (UTC+0100):
> > Windows uses local time for the hardware clock, Linux uses UTC.
>
> By default, yes, but not necessarily:
> https://wiki.archlinux.org/index.php/time#UTC_in_Windows

Ah!  It is a very long time since I used Windows and I had not remembered how 
I used to deal with it.

Lisi

Re: Time quandry when dual boot with WinXP Pro

[Felix Miata]

Lisi Reisz composed on 2016-10-29 15:44 (UTC+0100):


Windows uses local time for the hardware clock, Linux uses UTC.


By default, yes, but not necessarily:
https://wiki.archlinux.org/index.php/time#UTC_in_Windows
--
"The wise are known for their understanding, and pleasant
words are persuasive." Proverbs 16:21 (New Living Translation)

 Team OS/2 ** Reg. Linux User #211409 ** a11y rocks!

Felix Miata  ***  http://fm.no-ip.com/

Re: Time quandry when dual boot with WinXP Pro

[Lisi Reisz]

On Friday 21 October 2016 14:09:38 Richard Owlett wrote:
> I'm creating a preseed.cfg file for installing Debian 8.6 in a
> dual-boot enviroment with some version of MS Windows. There are
> two distinct use cases:
> 1. Two of my machines with WinXP Pro SP3
> 2. A remote (~1000 miles]friend with several machines - some
> with WinXP, others with
>Windows 10 or later.
>
> I have discovered on my WinXP machine that:
> 1. WinXP _displays_ the correct time.
>"Date and Time Properties" - Time Zone set to
>(GMT-06:00)Central Time(US)
>Automatically adjust clock for daylight saving changes
> 2. Debian 8.6 w MATE run from LIVE DVD _displays_ the correct
> time
> 3. Debian 8.6 w MATE installed from DVD 1 of 13 with aid of
> custom preseed.cfg
>_displays_ a time 5 hours earlier.
>The _display_ is independent of whether
> d-i clock-setup/utc boolean true
> *OR*
> d-i clock-setup/utc boolean false
>is used in the preseed.cfg file.
>
> I'm confused.

Windows uses local time for the hardware clock, Linux uses UTC.  The Live CD 
presumably uses its common sense when looking at the machine on which it is 
required to run.  I don't know.  I am not familiar with the Live CD.

You are presumably at GMT-5, hence displaying 5 hours earlier on the 
assumption that your hardware clock is set to UTC.

Lisi

[REPOST] Re: Time quandry when dual boot with WinXP Pro

[Richard Owlett]

On 10/22/2016 3:15 PM, Stefan Monnier wrote:

2. Debian 8.6 w MATE run from LIVE DVD _displays_ the correct time
3. Debian 8.6 w MATE installed from DVD 1 of 13 with aid of custom
preseed.cfg
_displays_ a time 5 hours earlier.

My guess: the Live DVD uses NTP so as not to depend on the hwclock
whereas your installs don't.

As the saying goes, "that does not compute".  The machine in question has not
been connected to the internet, or any other network, for several years ;/


Simple: over all these years its lust for a network connection was so
strong that it managed to find a way to get to the Internet.


 Stefan




You may have identified the problem after all ;/
What might the side effects of specifying use of NTP on 
installation be?
Is there something I can tweak in the *installed* system to 
duplicate what would have been done if the use of NTP had been 
specified in preseed.cfg?
Even given an affirmative answer to above, I can do a complete 
reinstall to assist in tracking possible side effects -- there is 
no valuable data on that machine.

Side effects of specifying use of NTP on installation???? - was [Re: Time quandry when dual boot with WinXP Pro]

[Richard Owlett]

On 10/22/2016 3:15 PM, Stefan Monnier wrote:

2. Debian 8.6 w MATE run from LIVE DVD _displays_ the correct time
3. Debian 8.6 w MATE installed from DVD 1 of 13 with aid of custom
preseed.cfg
_displays_ a time 5 hours earlier.

My guess: the Live DVD uses NTP so as not to depend on the hwclock
whereas your installs don't.

As the saying goes, "that does not compute".  The machine in question has not
been connected to the internet, or any other network, for several years ;/


Simple: over all these years its lust for a network connection was so
strong that it managed to find a way to get to the Internet.


 Stefan




You may have identified the problem after all ;/
What might the side effects of specifying use of NTP on 
installation be?
Is there something I can tweak in the *installed* system to 
duplicate what would have been done if the use of NTP had been 
specified in preseed.cfg?
Even given an affirmative answer to above, I can do a complete 
reinstall to assist in tracking possible side effects -- there is 
no valuable data on that machine.

Re: Time quandry when dual boot with WinXP Pro

[David Wright]

On Sat 22 Oct 2016 at 16:42:57 (+0100), Joe wrote:
> On Sat, 22 Oct 2016 09:57:05 -0500
> David Wright  wrote:
> 
> > On Fri 21 Oct 2016 at 18:47:43 (+0100), Joe wrote:
> > > On Fri, 21 Oct 2016 09:58:42 -0500
> > > David Wright  wrote:  
> > > > 
> > > > . Neither OS was running when Civil Time changed to/from DST,
> > > > . After the time changed, one OS has run, updating the Local Time
> > > > to match Civil Time, . Another OS is just being booted up.
> > > > 
> > > > What Local Time will eventually be displayed by this system?
> > > >   
> > > DST may well be the answer.  
> > 
> > (I can't see how that answers anything, as I hadn't specified which
> > way time changed, nor can I see why it would be an answer in either
> > case.)
> 
> It is *a* reason for inter-OS time shifting, it may be applicable to
> your or other peoples' cases.
> > 
> > My concern is that the second OS to boot might apply the time change
> > in exactly the same manner as the first one did and should have done.
> > So the system's Local Time would end up an hour fast (were this late
> > Spring) or slow (were this late Fall) after the second OS applied its
> > own time change.
> > 
> > Or IOW what mechanism is there for one OS to find out whether another
> > OS has altered the RTC by an hour any time recently?¹
> > 
> > > If I boot Linux on my Win8 laptop in the
> > > summer, it knows the time perfectly well. If I now boot Win8, the
> > > clock is an hour ahead. It does use a network time source but it
> > > does not query the source on boot, or soon afterwards. Eventually
> > > it will do so, but on a fixed schedule, so not for days, and there
> > > seems to be no way to fix it. It's not just the first time after
> > > DST arrives, it's every time.  
> > 
> > But isn't that just a configuration problem which I assume is unusual
> > in that most people are not reporting that problem? What's more, you
> > don't say whether your RTC is running UTC or some other time.
> > 
> > Ignoring drift, a RTC running UTC never changes, so the hardware
> > always knows the correct time. The Local Time displayed is just a
> > matter of sensible configuration.
> > 
> > My question, posed above, is *only* of concern where the RTC is
> > running non-UTC, ie it gets fiddled with twice a year. At these two
> > times, the RTC could be subject to incorrect alterations by
> > erroneously configured OSes, or even multiple OSes perfectly
> > configured, but unaware of each other's actions.
> 
> I'm making the point that it isn't just at the point of change of DST
> that this happens, but at any time when DST is active. Both OSes use
> network time updates routinely, not just when they think the clock is
> wrong (how could they tell otherwise?).

Ah, now I realise why I couldn't understand your first answer: we're
discussing a different problem. You're talking about the static
problem of getting linux and windows to interpret the RTC in a way
that is compatible with each other.

My question relates to the OP's situation with no networking/NTP, but
where the static configuration problems have been solved (where you've
not succeeded), but with the RTC running non-UTC. And my question
relates to the dynamic situation on two Sunday mornings of the year.
I can sum it up as:

With multiple OSes booting at various times, which OS is going to
change the RTC by an hour, and how is it to communicate that it has
done so to all the other OSes present on the computer, in order to
prevent each one thinking that it has to make that change because
*it* has total responsibility for the RTC.

The six bullet points were to make the scenario concrete. One OS
has changed the RTC to the new Local Time. It didn't use NTP to
lookup the time; it merely noted that the time change must have
occurred since the last boot, say, a week ago. The computer is happy.

Now we boot up a second OS which makes the same observation: "Hey,
I need to update Local Time because everyone changed their clocks
last weekend." Do you see the problem? I don't see how to avoid it
if you don't run a computer with RTC on UTC.

> The issue is that when I made the Linux installation, I told it that
> the hardware clock should be set to UTC (the default), whereas the
> Windows installation will always assume local time.

I was under the impression that the solution (from Darac) was to set
HKLM\SYSTEM\CurrentControlSet\Control\TimeZoneInformation\RealTimeIsUniversal
to 0 or 1 in the registry. Do you do that?

> The two OSes will
> always be an hour out during the DST period, and if you're not in the
> UTC time zone, there will be a further offset at all times. This has
> always been an issue when dual-booting, when you would normally tell
> Linux to consider the HW clock to use local time as a workaround.

I have to admit that I don't know how linux treats the time changes
when the RTC is on Local Time. Does it look at /etc/timezone and the
calendar and make the 

Re: Time quandry when dual boot with WinXP Pro

[Stefan Monnier]

>>> 2. Debian 8.6 w MATE run from LIVE DVD _displays_ the correct time
>>> 3. Debian 8.6 w MATE installed from DVD 1 of 13 with aid of custom
>>> preseed.cfg
>>> _displays_ a time 5 hours earlier.
>> My guess: the Live DVD uses NTP so as not to depend on the hwclock
>> whereas your installs don't.
> As the saying goes, "that does not compute".  The machine in question has not
> been connected to the internet, or any other network, for several years ;/

Simple: over all these years its lust for a network connection was so
strong that it managed to find a way to get to the Internet.


Stefan

Re: Time quandry when dual boot with WinXP Pro

[Richard Owlett]

On 10/22/2016 2:56 PM, Stefan Monnier wrote:

2. Debian 8.6 w MATE run from LIVE DVD _displays_ the correct time
3. Debian 8.6 w MATE installed from DVD 1 of 13 with aid of custom
preseed.cfg
   _displays_ a time 5 hours earlier.


My guess: the Live DVD uses NTP so as not to depend on the hwclock
whereas your installs don't.


As the saying goes, "that does not compute". The machine in 
question has not been connected to the internet, or any other 
network, for several years ;/

Re: Time quandry when dual boot with WinXP Pro

[Stefan Monnier]

>2. Debian 8.6 w MATE run from LIVE DVD _displays_ the correct time
>3. Debian 8.6 w MATE installed from DVD 1 of 13 with aid of custom
> preseed.cfg
>   _displays_ a time 5 hours earlier.

My guess: the Live DVD uses NTP so as not to depend on the hwclock
whereas your installs don't.


Stefan

Re: Time quandry when dual boot with WinXP Pro

[Joe]

On Sat, 22 Oct 2016 09:57:05 -0500
David Wright  wrote:

> On Fri 21 Oct 2016 at 18:47:43 (+0100), Joe wrote:
> > On Fri, 21 Oct 2016 09:58:42 -0500
> > David Wright  wrote:  
> > > 
> > > . Neither OS was running when Civil Time changed to/from DST,
> > > . After the time changed, one OS has run, updating the Local Time
> > > to match Civil Time, . Another OS is just being booted up.
> > > 
> > > What Local Time will eventually be displayed by this system?
> > >   
> > DST may well be the answer.  
> 
> (I can't see how that answers anything, as I hadn't specified which
> way time changed, nor can I see why it would be an answer in either
> case.)

It is *a* reason for inter-OS time shifting, it may be applicable to
your or other peoples' cases.
> 
> My concern is that the second OS to boot might apply the time change
> in exactly the same manner as the first one did and should have done.
> So the system's Local Time would end up an hour fast (were this late
> Spring) or slow (were this late Fall) after the second OS applied its
> own time change.
> 
> Or IOW what mechanism is there for one OS to find out whether another
> OS has altered the RTC by an hour any time recently?¹
> 
> > If I boot Linux on my Win8 laptop in the
> > summer, it knows the time perfectly well. If I now boot Win8, the
> > clock is an hour ahead. It does use a network time source but it
> > does not query the source on boot, or soon afterwards. Eventually
> > it will do so, but on a fixed schedule, so not for days, and there
> > seems to be no way to fix it. It's not just the first time after
> > DST arrives, it's every time.  
> 
> But isn't that just a configuration problem which I assume is unusual
> in that most people are not reporting that problem? What's more, you
> don't say whether your RTC is running UTC or some other time.
> 
> Ignoring drift, a RTC running UTC never changes, so the hardware
> always knows the correct time. The Local Time displayed is just a
> matter of sensible configuration.
> 
> My question, posed above, is *only* of concern where the RTC is
> running non-UTC, ie it gets fiddled with twice a year. At these two
> times, the RTC could be subject to incorrect alterations by
> erroneously configured OSes, or even multiple OSes perfectly
> configured, but unaware of each other's actions.

I'm making the point that it isn't just at the point of change of DST
that this happens, but at any time when DST is active. Both OSes use
network time updates routinely, not just when they think the clock is
wrong (how could they tell otherwise?).

The issue is that when I made the Linux installation, I told it that
the hardware clock should be set to UTC (the default), whereas the
Windows installation will always assume local time. The two OSes will
always be an hour out during the DST period, and if you're not in the
UTC time zone, there will be a further offset at all times. This has
always been an issue when dual-booting, when you would normally tell
Linux to consider the HW clock to use local time as a workaround.

> 
> > I give it a kick manually, which of course involves entering an
> > admin password...  
> 
> which is the necessity we're trying to avoid.
> 
> ¹ There's another similar concern should you have more than one OS
> thinking it's responsible for measuring and taking account of clock
> drift. Whether this is going to concern people who are rebooting OSes
> all the time is moot.
> 
For most computers, a second or two of clock drift won't matter, if
network time is being used to reset it every few days or once per boot.

I found plenty of people with this problem, and a few solutions. None
of them worked, of course, this is the Internet. The brute force and
ignorance answer is a script to force a network time update on Windows
soon after boot, as Linux does, but it happens to me so rarely that I
haven't yet worked up the enthusiasm. There's apparently no Windows
configuration flag to do this, or at least not in 8.

The laptop runs Windows pretty much all the time, but I occasionally
visit an establishment with free public wifi. I won't use Windows on a
network like that, so I have a Debian installation on a USB hard drive
which I boot from on those occasions, which resets my hardware clock to
UTC. This *is* the behaviour I want when booting my netbook from this
drive, which I do more often, so there's no configuration which will
keep the laptop happy.

-- 
Joe

Re: Time quandry when dual boot with WinXP Pro

[Joe]

On Sat, 22 Oct 2016 09:57:05 -0500
David Wright  wrote:

> On Fri 21 Oct 2016 at 18:47:43 (+0100), Joe wrote:
> > On Fri, 21 Oct 2016 09:58:42 -0500
> > David Wright  wrote:  
> > > 
> > > . Neither OS was running when Civil Time changed to/from DST,
> > > . After the time changed, one OS has run, updating the Local Time
> > > to match Civil Time, . Another OS is just being booted up.
> > > 
> > > What Local Time will eventually be displayed by this system?
> > >   
> > DST may well be the answer.  
> 
> (I can't see how that answers anything, as I hadn't specified which
> way time changed, nor can I see why it would be an answer in either
> case.)
> 
> My concern is that the second OS to boot might apply the time change
> in exactly the same manner as the first one did and should have done.
> So the system's Local Time would end up an hour fast (were this late
> Spring) or slow (were this late Fall) after the second OS applied its
> own time change.
> 
> Or IOW what mechanism is there for one OS to find out whether another
> OS has altered the RTC by an hour any time recently?¹
> 
> > If I boot Linux on my Win8 laptop in the
> > summer, it knows the time perfectly well. If I now boot Win8, the
> > clock is an hour ahead. It does use a network time source but it
> > does not query the source on boot, or soon afterwards. Eventually
> > it will do so, but on a fixed schedule, so not for days, and there
> > seems to be no way to fix it. It's not just the first time after
> > DST arrives, it's every time.  
> 
> But isn't that just a configuration problem which I assume is unusual
> in that most people are not reporting that problem? What's more, you
> don't say whether your RTC is running UTC or some other time.
> 
> Ignoring drift, a RTC running UTC never changes, so the hardware
> always knows the correct time. The Local Time displayed is just a
> matter of sensible configuration.
> 
> My question, posed above, is *only* of concern where the RTC is
> running non-UTC, ie it gets fiddled with twice a year. At these two
> times, the RTC could be subject to incorrect alterations by
> erroneously configured OSes, or even multiple OSes perfectly
> configured, but unaware of each other's actions.
> 
> > I give it a kick manually, which of course involves entering an
> > admin password...  
> 
> which is the necessity we're trying to avoid.
> 
> ¹ There's another similar concern should you have more than one OS
> thinking it's responsible for measuring and taking account of clock
> drift. Whether this is going to concern people who are rebooting OSes
> all the time is moot.
> 
> Cheers,
> David.
> 

Re: Time quandry when dual boot with WinXP Pro

[David Wright]

On Fri 21 Oct 2016 at 18:47:43 (+0100), Joe wrote:
> On Fri, 21 Oct 2016 09:58:42 -0500
> David Wright  wrote:
> > 
> > . Neither OS was running when Civil Time changed to/from DST,
> > . After the time changed, one OS has run, updating the Local Time to
> > match Civil Time, . Another OS is just being booted up.
> > 
> > What Local Time will eventually be displayed by this system?
> > 
> DST may well be the answer.

(I can't see how that answers anything, as I hadn't specified which way
time changed, nor can I see why it would be an answer in either case.)

My concern is that the second OS to boot might apply the time change
in exactly the same manner as the first one did and should have done.
So the system's Local Time would end up an hour fast (were this late
Spring) or slow (were this late Fall) after the second OS applied its
own time change.

Or IOW what mechanism is there for one OS to find out whether another
OS has altered the RTC by an hour any time recently?¹

> If I boot Linux on my Win8 laptop in the
> summer, it knows the time perfectly well. If I now boot Win8, the clock
> is an hour ahead. It does use a network time source but it does not
> query the source on boot, or soon afterwards. Eventually it will do so,
> but on a fixed schedule, so not for days, and there seems to be no way
> to fix it. It's not just the first time after DST arrives, it's every
> time.

But isn't that just a configuration problem which I assume is unusual
in that most people are not reporting that problem? What's more, you
don't say whether your RTC is running UTC or some other time.

Ignoring drift, a RTC running UTC never changes, so the hardware
always knows the correct time. The Local Time displayed is just a
matter of sensible configuration.

My question, posed above, is *only* of concern where the RTC is running
non-UTC, ie it gets fiddled with twice a year. At these two times, the
RTC could be subject to incorrect alterations by erroneously configured
OSes, or even multiple OSes perfectly configured, but unaware of each
other's actions.

> I give it a kick manually, which of course involves entering an admin
> password...

which is the necessity we're trying to avoid.

¹ There's another similar concern should you have more than one OS
thinking it's responsible for measuring and taking account of clock
drift. Whether this is going to concern people who are rebooting OSes
all the time is moot.

Cheers,
David.

Re: Time quandry when dual boot with WinXP Pro

[tomas]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On Fri, Oct 21, 2016 at 03:09:46PM -0500, Richard Owlett wrote:

[...]

If you want to get to the ground of things, on my system (yes, I'm on SysV
init, for systemd you'll have to find out for yourself), the magic happens
in /etc/init.d/hwclock.sh. This happens pretty early at boot.

Now you'd have to find out when the relevant d-i setting takes place.

Let us know :-)

regards
- -- tomás
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.12 (GNU/Linux)

iEYEARECAAYFAlgKe5QACgkQBcgs9XrR2kYAAACbBFdyBLP8NGPXg4OdQCB5Q/Ov
dvMAn0Dr26NUzXBnAmENuIdByIuh69XB
=QW2v
-END PGP SIGNATURE-

Re: Time quandry when dual boot with WinXP Pro

[Richard Owlett]

On 10/21/2016 2:24 PM, to...@tuxteam.de wrote:



On Fri, Oct 21, 2016 at 09:11:07PM +0200, to...@tuxteam.de wrote:

On Fri, Oct 21, 2016 at 09:21:17AM -0500, Richard Owlett wrote:

[...]


Relevant lines of preseed.cfg are

### Clock and time zone setup
#d-i clock-setup/utc boolean false
d-i clock-setup/utc boolean true
d-i time/zone string US/Central
d-i clock-setup/ntp boolean false


To me this looks reasonable. At least the installer should have enough
info to get by.

Note that I'm not very fluent on the details, so I might be missing
something.


Here are the relevant pages [1] [2].


[1] & [2] bother me a little as they are labeled "(Obsolete 
Documentation)"

They should imply possible search terms for additional research.
My current motto - "If retirement isn't for learning, what use is 
it?"   ;/


[3] also looks applicable. Will read all 3 after good night's sleep.
Got a couple of other problems I should address today ;/



In a nutshell, it *should* work. But you lose the automatic DST change --
the OS expects then the HW clock to be "right" wrt local time.

But -- who knows? Perhaps the hwclock is read *before* the d-i settings
can be accounted for; perhaps the time will be right after installation
*and* reboot?

[1] 
https://www.debian.org/doc/manuals/system-administrator/ch-sysadmin-time.html
[2] 
https://www.debian.org/doc/manuals/system-administrator/ch-sysadmin-time.html#s-multiboot-with


[3] 
https://www.debian.org/doc/manuals/debian-handbook/sect.config-misc.en.html





regards

Re: Time quandry when dual boot with WinXP Pro

[tomas]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On Fri, Oct 21, 2016 at 09:11:07PM +0200, to...@tuxteam.de wrote:
> On Fri, Oct 21, 2016 at 09:21:17AM -0500, Richard Owlett wrote:
> 
> [...]
> 
> > Relavant lines of preseed.cfg are
> > 
> > ### Clock and time zone setup
> > #d-i clock-setup/utc boolean false
> > d-i clock-setup/utc boolean true
> > d-i time/zone string US/Central
> > d-i clock-setup/ntp boolean false
> 
> To me this looks reasonable. At least the installer should have enough
> info to get by.
> 
> Note that I'm not very fluent on the details, so I might be missing
> something.

Here are the relevant pages [1] [2].

In a nutshell, it *should* work. But you lose the automatic DST change --
the OS expects then the HW clock to be "right" wrt local time.

But -- who knows? Perhaps the hwclock is read *before* the d-i settings
can be accounted for; perhaps the time will be right after installation
*and* reboot?

[1] 
https://www.debian.org/doc/manuals/system-administrator/ch-sysadmin-time.html
[2] 
https://www.debian.org/doc/manuals/system-administrator/ch-sysadmin-time.html#s-multiboot-with

regards
- -- t
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.12 (GNU/Linux)

iEYEARECAAYFAlgKa18ACgkQBcgs9XrR2ka/wgCeNe9AumWLYJ3WBIG9eQuB1SLc
fl4An0dEE+FYI91/RXelQQF1tVcXqzO1
=XANW
-END PGP SIGNATURE-

Re: Time quandry when dual boot with WinXP Pro

[tomas]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On Fri, Oct 21, 2016 at 01:17:21PM -0500, Richard Owlett wrote:

[...]

> CONCLUSION
> Can *NOT* blame Microsoft Windows for EVERYTHING ;/

My conclusion too. There's something else acting up. Linux should
pick up the hw clock and *know* it's not in UTC, but in the noted
timezone. Hmmm.

regards
- -- t
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.12 (GNU/Linux)

iEYEARECAAYFAlgKaMwACgkQBcgs9XrR2kYfdACfewFmXgPBX2BQKDZ5nVvoWTCr
GuQAn3eAN+ZDtL6Sv8Y30vHRbaXx/5L+
=UMEO
-END PGP SIGNATURE-

Re: Time quandry when dual boot with WinXP Pro

[tomas]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On Fri, Oct 21, 2016 at 09:21:17AM -0500, Richard Owlett wrote:

[...]

> Relavant lines of preseed.cfg are
> 
> ### Clock and time zone setup
> #d-i clock-setup/utc boolean false
> d-i clock-setup/utc boolean true
> d-i time/zone string US/Central
> d-i clock-setup/ntp boolean false

To me this looks reasonable. At least the installer should have enough
info to get by.

Note that I'm not very fluent on the details, so I might be missing
something.

regards
- -- t
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.12 (GNU/Linux)

iEYEARECAAYFAlgKaEsACgkQBcgs9XrR2kYisACePF8aAPUqrKh8bauMcYo5knvj
wN4An2XW5A/HGXxUuCP2q5/R4XpqZ3F+
=a9Gh
-END PGP SIGNATURE-

Re: Time quandry when dual boot with WinXP Pro

[Richard Owlett]

On 10/21/2016 11:46 AM, Doug wrote:


On 10/21/2016 10:21 AM, Richard Owlett wrote:

On 10/21/2016 8:32 AM, to...@tuxteam.de wrote:

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On Fri, Oct 21, 2016 at 08:09:38AM -0500, Richard Owlett wrote:

I'm creating a preseed.cfg file for installing Debian 8.6 in a
dual-boot environment with some version of MS Windows. There
are two
distinct use cases:
1. Two of my machines with WinXP Pro SP3
2. A remote (~1000 miles]friend with several machines -
some with
WinXP, others with
   Windows 10 or later.


Uh, oh. Microsoft and time handling. This won't end well :-/


*ROFL*



*KEY* text text from original post was not quoted.


I have discovered on my WinXP machine that:
   1. WinXP _displays_ the correct time.
  "Date and Time Properties" - Time Zone set to
  (GMT-06:00)Central Time(US)
  Automatically adjust clock for daylight saving changes
   2. Debian 8.6 w MATE run from LIVE DVD _displays_ the correct 
time




3. Debian 8.6 w MATE installed from DVD 1 of 13 with aid
of custom preseed.cfg
   _displays_ a time 5 hours earlier.
   The _display_ is independent of whether
d-i clock-setup/utc boolean true
*OR*
d-i clock-setup/utc boolean false




Yes, It's Windows' fault. Unfortunately, I don't remember the
details, but the cure is in the Registry.
If you google the problem, somewhere along the way, you will find
the Registry hack that fixes
the problem.


*Begin test sequence*
power off
power on
start Debian - time displayed 08:00 AM
power off
power on
start WinXP Pro SP3 - time displayed 01:00 PM
"Shut Down Windows" choosing "Restart" menu option
Chose Debian from Grub menu - time displayed 08:00 AM
shut down with restart option
Run Debian from Live DVD - time displayed 13:12
Shut down with power off
power on
Run Debian from Live DVD - time displayed 13:12
*EOT*

CONCLUSION
Can *NOT* blame Microsoft Windows for EVERYTHING ;/




--doug

This observation alone suggests strongly that this installation
"thinks" it should use the UTC (or any equivalent) time zone
to fudge back its way from the hardware clock to the UTC.

What is the value of d-i time/zone?


Relevant lines of preseed.cfg are

### Clock and time zone setup
#d-i clock-setup/utc boolean false
d-i clock-setup/utc boolean true
d-i time/zone string US/Central
d-i clock-setup/ntp boolean false





regards
- -- tomás

Re: Time quandry when dual boot with WinXP Pro

[Joe]

On Fri, 21 Oct 2016 09:58:42 -0500
David Wright  wrote:


> 
> . Neither OS was running when Civil Time changed to/from DST,
> . After the time changed, one OS has run, updating the Local Time to
> match Civil Time, . Another OS is just being booted up.
> 
> What Local Time will eventually be displayed by this system?
> 


DST may well be the answer. If I boot Linux on my Win8 laptop in the
summer, it knows the time perfectly well. If I now boot Win8, the clock
is an hour ahead. It does use a network time source but it does not
query the source on boot, or soon afterwards. Eventually it will do so,
but on a fixed schedule, so not for days, and there seems to be no way
to fix it. It's not just the first time after DST arrives, it's every
time.

I give it a kick manually, which of course involves entering an admin
password...

-- 
Joe

Re: Time quandry when dual boot with WinXP Pro

[Doug]

On 10/21/2016 10:21 AM, Richard Owlett wrote:

On 10/21/2016 8:32 AM, to...@tuxteam.de wrote:

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On Fri, Oct 21, 2016 at 08:09:38AM -0500, Richard Owlett wrote:

I'm creating a preseed.cfg file for installing Debian 8.6 in a
dual-boot enviroment with some version of MS Windows. There are two
distinct use cases:
1. Two of my machines with WinXP Pro SP3
2. A remote (~1000 miles]friend with several machines - some with
WinXP, others with
   Windows 10 or later.


Uh, oh. Microsoft and time handling. This won't end well :-/


*ROFL*

3. Debian 8.6 w MATE installed from DVD 1 of 13 with aid of 
custom preseed.cfg

   _displays_ a time 5 hours earlier.
   The _display_ is independent of whether
d-i clock-setup/utc boolean true
*OR*
d-i clock-setup/utc boolean false


Yes, It's Windows' fault. Unfortunately, I don't remember the details, 
but the cure is in the Registry.
If you google the problem, somewhere along the way, you will find the 
Registry hack that fixes

the problem.

--doug

This observation alone suggests strongly that this installation
"thinks" it should use the UTC (or any equivalent) time zone
to fudge back its way from the hardware clock to the UTC.

What is the value of d-i time/zone?


Relavant lines of preseed.cfg are

### Clock and time zone setup
#d-i clock-setup/utc boolean false
d-i clock-setup/utc boolean true
d-i time/zone string US/Central
d-i clock-setup/ntp boolean false





regards
- -- tomás
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.12 (GNU/Linux)

iEYEARECAAYFAlgKGNkACgkQBcgs9XrR2kbE3wCfazy79csBl1oVWD0IZp5D2nGZ
bUMAnivHeC+RC3CfgBy7LzoAD16wCZaF
=wguH
-END PGP SIGNATURE-

Re: Time quandry when dual boot with WinXP Pro

[David Wright]

On Fri 21 Oct 2016 at 14:28:26 (+0100), Darac Marjal wrote:
> On Fri, Oct 21, 2016 at 08:09:38AM -0500, Richard Owlett wrote:
> >I'm creating a preseed.cfg file for installing Debian 8.6 in a
> >dual-boot enviroment with some version of MS Windows. There are
> >two distinct use cases:
> >  [snipped]
> 
> If you're not using NTP to provide your time, then, at boot, the
> operating system will query the "hardware clock" to see what time it
> is.  As the hardware clock can drift, operating systems will also
> set the hardware clock to match the "system clock" at shutdown time
> (the system clock is the time that the operating system is using).
> 
> The problem comes that there is no way for the hardware clock
> (HWClock) to report what timezone it was set to. There are basically
> two options here:
> 
> 1. The HWClock is set to "Local Time". In this case, the operating
> system sees "12:23" as being "12:23 GMT" or "12:23 CST" or whatever
> and attempts no translation of the clock.
> 
> 2. The HWClock is set to "Universal Time" (which is a
> non-geographical datum time zone, with no daylight changes). In this
> case, the operating system sees "12:23" as ONLY being "12:23 UTC"
> and translates that into the local time zone by adding or
> subtracting hours appropriately.
> 
> If you only have one operating system on your machine, either of
> these methods is fine. If you have TWO (or more) operating systems,
> though, then they SHOULD agree on what the time in the HWClock
> represents. If Windows thinks it's local time, but Debian thinks
> it's UTC, then you'll see five-hour shifts each time you boot.
> 
> You've already found the setting in Debian, I see, so you probably
> want to check it tallies with what Windows is using. For that, look
> at the Registry Key 
> HKLM\SYSTEM\CurrentControlSet\Control\TimeZoneInformation\RealTimeIsUniversal.
> If this is 1, then the HWClock is using UTC; if it is 0, then the
> HWClock is set to local time.

So what happens with the scenario:

. No NTP connection,
. Hardware clock running on Local Time,
. Two or more OSes that know these two facts.

. Neither OS was running when Civil Time changed to/from DST,
. After the time changed, one OS has run, updating the Local Time to match 
Civil Time,
. Another OS is just being booted up.

What Local Time will eventually be displayed by this system?

Cheers,
David.

Re: Time quandry when dual boot with WinXP Pro

[Richard Owlett]

On 10/21/2016 8:28 AM, Darac Marjal wrote:

On Fri, Oct 21, 2016 at 08:09:38AM -0500, Richard Owlett wrote:

I'm creating a preseed.cfg file for installing Debian 8.6 in a
dual-boot enviroment with some version of MS Windows. There are
two distinct use cases:
  1. Two of my machines with WinXP Pro SP3
  2. A remote (~1000 miles]friend with several machines - some
with WinXP, others with
 Windows 10 or later.

I have discovered on my WinXP machine that:
  1. WinXP _displays_ the correct time.
 "Date and Time Properties" - Time Zone set to
 (GMT-06:00)Central Time(US)
 Automatically adjust clock for daylight saving changes
  2. Debian 8.6 w MATE run from LIVE DVD _displays_ the correct
time
  3. Debian 8.6 w MATE installed from DVD 1 of 13 with aid of
custom preseed.cfg
 _displays_ a time 5 hours earlier.
 The _display_ is independent of whether
  d-i clock-setup/utc boolean true
  *OR*
  d-i clock-setup/utc boolean false
 is used in the preseed.cfg file.

I'm confused.


If you're not using NTP to provide your time,


Mine are not. His I don't know.


then, at boot, the
operating system will query the "hardware clock" to see what time
it is. As the hardware clock can drift, operating systems will
also set the hardware clock to match the "system clock" at
shutdown time (the system clock is the time that the operating
system is using).

The problem comes that there is no way for the hardware clock
(HWClock) to report what timezone it was set to. There are
basically two options here:

1. The HWClock is set to "Local Time". In this case, the
operating system sees "12:23" as being "12:23 GMT" or "12:23 CST"
or whatever and attempts no translation of the clock.

2. The HWClock is set to "Universal Time" (which is a
non-geographical datum time zone, with no daylight changes). In
this case, the operating system sees "12:23" as ONLY being "12:23
UTC" and translates that into the local time zone by adding or
subtracting hours appropriately.

If you only have one operating system on your machine, either of
these methods is fine. If you have TWO (or more) operating
systems, though, then they SHOULD agree on what the time in the
HWClock represents. If Windows thinks it's local time, but Debian
thinks it's UTC, then you'll see five-hour shifts each time you
boot.

You've already found the setting in Debian, I see, so you
probably want to check it tallies with what Windows is using. For
that, look at the Registry Key
HKLM\SYSTEM\CurrentControlSet\Control\TimeZoneInformation\RealTimeIsUniversal.
If this is 1, then the HWClock is using UTC; if it is 0, then the
HWClock is set to local time.


On my system, regedit does not display that key. Instead it has

HKLM\SYSTEM\CurrentControlSet\Control\TimeZoneInformation\ActiveTimeBias
HKLM\SYSTEM\CurrentControlSet\Control\TimeZoneInformation\Bias

HKLM\SYSTEM\CurrentControlSet\Control\TimeZoneInformation\StandardBias
with respective values of (300), (360), and (0)



Hopefully that helps.


It clarifies what's happening. For my pesonal machines it doesn't 
make much difference, will likely just go to UTC for both clock 
and displayed time.


For my friend's machines there are non-technical, as well as 
technical, issues involved.

Re: Time quandry when dual boot with WinXP Pro

[Richard Owlett]

On 10/21/2016 8:32 AM, to...@tuxteam.de wrote:

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On Fri, Oct 21, 2016 at 08:09:38AM -0500, Richard Owlett wrote:

I'm creating a preseed.cfg file for installing Debian 8.6 in a
dual-boot enviroment with some version of MS Windows. There are two
distinct use cases:
1. Two of my machines with WinXP Pro SP3
2. A remote (~1000 miles]friend with several machines - some with
WinXP, others with
   Windows 10 or later.


Uh, oh. Microsoft and time handling. This won't end well :-/


*ROFL*


3. Debian 8.6 w MATE installed from DVD 1 of 13 with aid of custom 
preseed.cfg
   _displays_ a time 5 hours earlier.
   The _display_ is independent of whether
d-i clock-setup/utc boolean true
*OR*
d-i clock-setup/utc boolean false


This observation alone suggests strongly that this installation
"thinks" it should use the UTC (or any equivalent) time zone
to fudge back its way from the hardware clock to the UTC.

What is the value of d-i time/zone?


Relavant lines of preseed.cfg are

### Clock and time zone setup
#d-i clock-setup/utc boolean false
d-i clock-setup/utc boolean true
d-i time/zone string US/Central
d-i clock-setup/ntp boolean false





regards
- -- tomás
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.12 (GNU/Linux)

iEYEARECAAYFAlgKGNkACgkQBcgs9XrR2kbE3wCfazy79csBl1oVWD0IZp5D2nGZ
bUMAnivHeC+RC3CfgBy7LzoAD16wCZaF
=wguH
-END PGP SIGNATURE-

Re: Time quandry when dual boot with WinXP Pro

[tomas]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On Fri, Oct 21, 2016 at 08:09:38AM -0500, Richard Owlett wrote:
> I'm creating a preseed.cfg file for installing Debian 8.6 in a
> dual-boot enviroment with some version of MS Windows. There are two
> distinct use cases:
>1. Two of my machines with WinXP Pro SP3
>2. A remote (~1000 miles]friend with several machines - some with
> WinXP, others with
>   Windows 10 or later.

Uh, oh. Microsoft and time handling. This won't end well :-/

[...]
>3. Debian 8.6 w MATE installed from DVD 1 of 13 with aid of custom 
> preseed.cfg
>   _displays_ a time 5 hours earlier.
>   The _display_ is independent of whether
>d-i clock-setup/utc boolean true
>*OR*
>d-i clock-setup/utc boolean false

This observation alone suggests strongly that this installation
"thinks" it should use the UTC (or any equivalent) time zone
to fudge back its way from the hardware clock to the UTC.

What is the value of d-i time/zone?

regards
- -- tomás
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.12 (GNU/Linux)

iEYEARECAAYFAlgKGNkACgkQBcgs9XrR2kbE3wCfazy79csBl1oVWD0IZp5D2nGZ
bUMAnivHeC+RC3CfgBy7LzoAD16wCZaF
=wguH
-END PGP SIGNATURE-

Re: Time quandry when dual boot with WinXP Pro

[Darac Marjal]

On Fri, Oct 21, 2016 at 08:09:38AM -0500, Richard Owlett wrote:
I'm creating a preseed.cfg file for installing Debian 8.6 in a 
dual-boot enviroment with some version of MS Windows. There are two 
distinct use cases:

  1. Two of my machines with WinXP Pro SP3
  2. A remote (~1000 miles]friend with several machines - some with 
WinXP, others with

 Windows 10 or later.

I have discovered on my WinXP machine that:
  1. WinXP _displays_ the correct time.
 "Date and Time Properties" - Time Zone set to
 (GMT-06:00)Central Time(US)
 Automatically adjust clock for daylight saving changes
  2. Debian 8.6 w MATE run from LIVE DVD _displays_ the correct time
  3. Debian 8.6 w MATE installed from DVD 1 of 13 with aid of custom 
preseed.cfg

 _displays_ a time 5 hours earlier.
 The _display_ is independent of whether
  d-i clock-setup/utc boolean true
  *OR*
  d-i clock-setup/utc boolean false
 is used in the preseed.cfg file.

I'm confused.


If you're not using NTP to provide your time, then, at boot, the 
operating system will query the "hardware clock" to see what time it is.  
As the hardware clock can drift, operating systems will also set the 
hardware clock to match the "system clock" at shutdown time (the system 
clock is the time that the operating system is using).


The problem comes that there is no way for the hardware clock (HWClock) 
to report what timezone it was set to. There are basically two options 
here:


1. The HWClock is set to "Local Time". In this case, the operating 
system sees "12:23" as being "12:23 GMT" or "12:23 CST" or whatever and 
attempts no translation of the clock.


2. The HWClock is set to "Universal Time" (which is a non-geographical 
datum time zone, with no daylight changes). In this case, the operating 
system sees "12:23" as ONLY being "12:23 UTC" and translates that into 
the local time zone by adding or subtracting hours appropriately.


If you only have one operating system on your machine, either of these 
methods is fine. If you have TWO (or more) operating systems, though, 
then they SHOULD agree on what the time in the HWClock represents. If 
Windows thinks it's local time, but Debian thinks it's UTC, then you'll 
see five-hour shifts each time you boot.


You've already found the setting in Debian, I see, so you probably want 
to check it tallies with what Windows is using. For that, look at the 
Registry Key 
HKLM\SYSTEM\CurrentControlSet\Control\TimeZoneInformation\RealTimeIsUniversal.  
If this is 1, then the HWClock is using UTC; if it is 0, then the 
HWClock is set to local time.


Hopefully that helps.








--
For more information, please reread.

Time quandry when dual boot with WinXP Pro

[Richard Owlett]

I'm creating a preseed.cfg file for installing Debian 8.6 in a 
dual-boot enviroment with some version of MS Windows. There are 
two distinct use cases:

   1. Two of my machines with WinXP Pro SP3
   2. A remote (~1000 miles]friend with several machines - some 
with WinXP, others with

  Windows 10 or later.

I have discovered on my WinXP machine that:
   1. WinXP _displays_ the correct time.
  "Date and Time Properties" - Time Zone set to
  (GMT-06:00)Central Time(US)
  Automatically adjust clock for daylight saving changes
   2. Debian 8.6 w MATE run from LIVE DVD _displays_ the correct 
time
   3. Debian 8.6 w MATE installed from DVD 1 of 13 with aid of 
custom preseed.cfg

  _displays_ a time 5 hours earlier.
  The _display_ is independent of whether
   d-i clock-setup/utc boolean true
   *OR*
   d-i clock-setup/utc boolean false
  is used in the preseed.cfg file.

I'm confused.