Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.debian.user > #201181 > unrolled thread

jessie and stretch time problem

Back to article view | Back to linux.debian.user

This discussion starts older than the indexed window; earlier articles aren't shown. The article labeled Started by below is the oldest one visible, not the original post.

Contents

  jessie and stretch time problem Long Wind <longwind2@yahoo.com> - 2018-10-13 00:10 +0200
    Re: jessie and stretch time problem Kenneth Parker <sea7kenp@gmail.com> - 2018-10-13 00:20 +0200
      Re: jessie and stretch time problem Long Wind <longwind2@yahoo.com> - 2018-10-13 00:40 +0200
        Re: jessie and stretch time problem Kenneth Parker <sea7kenp@gmail.com> - 2018-10-13 00:50 +0200
        Re: jessie and stretch time problem <tomas@tuxteam.de> - 2018-10-13 08:30 +0200
          Re: jessie and stretch time problem Long Wind <longwind2@yahoo.com> - 2018-10-13 09:20 +0200
            Re: jessie and stretch time problem <tomas@tuxteam.de> - 2018-10-14 09:50 +0200
              Re: jessie and stretch time problem Cindy-Sue Causey <butterflybytes@gmail.com> - 2018-10-14 15:30 +0200
                Re: jessie and stretch time problem Reco <recoverym4n@enotuniq.net> - 2018-10-14 16:30 +0200
                  Re: jessie and stretch time problem Brian <ad44@cityscape.co.uk> - 2018-10-14 20:20 +0200
                    Re: jessie and stretch time problem Reco <recoverym4n@enotuniq.net> - 2018-10-14 20:40 +0200
                      Re: jessie and stretch time problem Brian <ad44@cityscape.co.uk> - 2018-10-14 21:40 +0200
    Re: jessie and stretch time problem Teemu Likonen <tlikonen@iki.fi> - 2018-10-13 09:20 +0200
      (solved) Re: jessie and stretch time problem Long Wind <longwind2@yahoo.com> - 2018-10-13 09:30 +0200
        Re: (solved) Re: jessie and stretch time problem David Wright <deblis@lionunicorn.co.uk> - 2018-10-13 16:10 +0200
          Re: (solved) Re: jessie and stretch time problem Brian <ad44@cityscape.co.uk> - 2018-10-13 21:00 +0200
            Re: (solved) Re: jessie and stretch time problem Curt <curty@free.fr> - 2018-10-13 22:00 +0200
              Re: (solved) Re: jessie and stretch time problem David Wright <deblis@lionunicorn.co.uk> - 2018-10-13 23:00 +0200

#201181 — jessie and stretch time problem

[Multipart message — attachments visible in raw view] — view raw

jessie and stretch are installed on same PCtime of jessie is wrong: Fri Oct 12 21:51:05 CST 2018then i reboot and enter stretch
time of stretch is right: Sat Oct 13 05:55:30 CST 2018
tzdata of both are reconfig to same place

[toc] | [next] | [standalone]

#201182

[Multipart message — attachments visible in raw view] — view raw

On Fri, Oct 12, 2018 at 6:01 PM Long Wind <longwind2@yahoo.com> wrote:

> jessie and stretch are installed on same PC
> time of jessie is wrong: Fri Oct 12 21:51:05 CST 2018
> then i reboot and enter stretch
> time of stretch is right: Sat Oct 13 05:55:30 CST 2018
>
> tzdata of both are reconfig to same place
>

Is it possible that one is set to "Local Time", and the other to "UTC Time"?

I had that problem once, Dual Booting Windows XP (I'm Dating myself) and an
old version of Ubuntu.  Turned out to be an Education Issue:  Everything
was fine, when I changed Linux to "Local Time".   (Your issue may be the
opposite).

I forgot what I did to fix it.  (So Long Ago. LOL!)

Good Luck and Best Regards,

Kenneth Parker, Computer Consultant

[toc] | [prev] | [next] | [standalone]

#201183

[Multipart message — attachments visible in raw view] — view raw

Thanks! How could I find out  if debian thinks bios clock is set to local time or universal time? 

    On Saturday, October 13, 2018 6:13 AM, Kenneth Parker <sea7kenp@gmail.com> wrote:
 

 
On Fri, Oct 12, 2018 at 6:01 PM Long Wind <longwind2@yahoo.com> wrote:

jessie and stretch are installed on same PCtime of jessie is wrong: Fri Oct 12 21:51:05 CST 2018then i reboot and enter stretch
time of stretch is right: Sat Oct 13 05:55:30 CST 2018
tzdata of both are reconfig to same place


Is it possible that one is set to "Local Time", and the other to "UTC Time"?
I had that problem once, Dual Booting Windows XP (I'm Dating myself) and an old version of Ubuntu.  Turned out to be an Education Issue:  Everything was fine, when I changed Linux to "Local Time".   (Your issue may be the opposite). 
I forgot what I did to fix it.  (So Long Ago. LOL!)
Good Luck and Best Regards,
Kenneth Parker, Computer Consultant

   

[toc] | [prev] | [next] | [standalone]

#201184

[Multipart message — attachments visible in raw view] — view raw

On Fri, Oct 12, 2018 at 6:32 PM Long Wind <longwind2@yahoo.com> wrote:

> Thanks! How could I find out  if debian thinks bios clock is set to local
> time or universal time?
>

I looked it up.  Even though Arch Linux isn't Debian, I respect them, for
giving good, technical details about Linux Concepts.  Here's a Link:

https://wiki.archlinux.org/index.php/time


> Good Luck and Best Regards,
>
>
> Kenneth Parker, Computer Consultant
>
>
>

[toc] | [prev] | [next] | [standalone]

#201185

[Multipart message — attachments visible in raw view] — view raw

On Fri, Oct 12, 2018 at 10:32:16PM +0000, Long Wind wrote:
> Thanks! How could I find out  if debian thinks bios clock is set to local time or universal time? 

This is one way to do it:

  tomas@trotzki:~$ cat /etc/adjtime
  0.000000 1539378883 0.000000
  1539378883
  UTC

The last line will tell you whether the hwclock command is expecting
the hardware clock to be "ticking" UTC or local (if you haven't any
other OS like Windows booting from the same machine, UTC is strongly
recommended).

The other mysterious values are used to compensate inaccuracies of
the hardware clock itself.

Cheers
-- tomas

[toc] | [prev] | [next] | [standalone]

#201186

[Multipart message — attachments visible in raw view] — view raw

Thank tomas! 

i run "cat /etc/adjtime" in jessie and it says LOCALbut in stretch /etc/adjtime doesn't seem to exist
PS: i receive two copies of your mail.
 

    On Saturday, October 13, 2018 2:29 PM, "tomas@tuxteam.de" <tomas@tuxteam.de> wrote:
 

 On Fri, Oct 12, 2018 at 10:32:16PM +0000, Long Wind wrote:
> Thanks! How could I find out  if debian thinks bios clock is set to local time or universal time? 

This is one way to do it:

  tomas@trotzki:~$ cat /etc/adjtime
  0.000000 1539378883 0.000000
  1539378883
  UTC

The last line will tell you whether the hwclock command is expecting
the hardware clock to be "ticking" UTC or local (if you haven't any
other OS like Windows booting from the same machine, UTC is strongly
recommended).

The other mysterious values are used to compensate inaccuracies of
the hardware clock itself.

Cheers
-- tomas

   

[toc] | [prev] | [next] | [standalone]

#201207

[Multipart message — attachments visible in raw view] — view raw

On Sat, Oct 13, 2018 at 07:11:07AM +0000, Long Wind wrote:
> Thank tomas! 
> 
> i run "cat /etc/adjtime" in jessie and it says LOCALbut in stretch /etc/adjtime doesn't seem to exist

I see. Perhaps this is the root of the problem. On the other
hand, perhaps, systemd is taking care of time in stretch by
default. In that case I can't help, since my knowledge of
systemd is minimal.

> PS: i receive two copies of your mail.

Yes, sorry. I often CC the original post for the benefit of
those who are not subscribed. I haven't a good solution for
that, yet. Working on it :-)

Cheers
-- tomás

[toc] | [prev] | [next] | [standalone]

#201218

On 10/14/18, tomas@tuxteam.de <tomas@tuxteam.de> wrote:
> On Sat, Oct 13, 2018 at 07:11:07AM +0000, Long Wind wrote:
>> Thank tomas!
>>
>> i run "cat /etc/adjtime" in jessie and it says LOCALbut in stretch
>> /etc/adjtime doesn't seem to exist
>
> I see. Perhaps this is the root of the problem. On the other
> hand, perhaps, systemd is taking care of time in stretch by
> default. In that case I can't help, since my knowledge of
> systemd is minimal.


I was going to bring this up yesterday, just couldn't rope the words
in together. With debootstrap, one step the user manually does is
this:

+++ QUOTE k/t https://www.debian.org/releases/buster/amd64/apds03.en.html +++

D.3.4.3. Setting Timezone

Setting the third line of the file /etc/adjtime to “UTC” or “LOCAL”
determines whether the system will interpret the hardware clock as
being set to UTC respective local time. The following command allows
you to set that.

# editor /etc/adjtime

Here is a sample:

0.0 0 0.0

0
UTC

The following command allows you to choose your timezone.

# dpkg-reconfigure tzdata

+++ END QUOTE +++

Mine currently reflects the above months after it was entered. A
similar topic came up a while back while I was using a different
debootstrap'ed copy. For that one particular instance, all those
zeroes had changed to something else that made no sense to me but
surely meant something to the computer.

I don't know how that one change occurred unless I forgot the above
step during that particular debootstrap, and then maybe the system
filled in what it thought it needed. However that change occurred, it
worked at the time because there was no notable difference in how time
was presented. ? :)

Cindy :)
-- 
Cindy-Sue Causey
Talking Rock, Pickens County, Georgia, USA

* runs with duct tape *

[toc] | [prev] | [next] | [standalone]

#201219

	Hi.

On Sun, Oct 14, 2018 at 09:22:53AM -0400, Cindy-Sue Causey wrote:
> On 10/14/18, tomas@tuxteam.de <tomas@tuxteam.de> wrote:
> > On Sat, Oct 13, 2018 at 07:11:07AM +0000, Long Wind wrote:
> >> Thank tomas!
> >>
> >> i run "cat /etc/adjtime" in jessie and it says LOCALbut in stretch
> >> /etc/adjtime doesn't seem to exist
> >
> > I see. Perhaps this is the root of the problem. On the other
> > hand, perhaps, systemd is taking care of time in stretch by
> > default. In that case I can't help, since my knowledge of
> > systemd is minimal.
> 
> 
> I was going to bring this up yesterday, just couldn't rope the words
> in together. With debootstrap, one step the user manually does is
> this:
> 
> +++ QUOTE k/t https://www.debian.org/releases/buster/amd64/apds03.en.html +++

That guide contains curious relics of the past that include, but aren't
limited to:

1) 'lo' interface in /etc/network/interfaces - unneeded even with
stretch's ifupdown.

2) 'hostname' record in /etc/hosts - unneeded with libnss-myhostname.

3) '.local' domain at /etc/resolv.conf - a direct violation of RFC 6762.

4) At controversial (to say the least) recommendation to use 'deb-src'
of Debian main suite without actually specifying 'deb'.

5) The /etc/adjtime configuration itself.
Systemd defaults to UTC - src/timedate/timedated.c in systemd source
tree.
If needed, one can use timedatectl(1) to produce perfectly valid
/etc/adjtime.


> D.3.4.3. Setting Timezone

Of course, whoever wrote this certainly considered *other* init systems
that Debian ships - unlike systemd-timedated, sysvinit, openrc and
upstart rely on hwclock(8).

But since removing systemd from modern Debian takes certain skill and
determination and a reason to do so - I somehow doubt that OP's problem
can be explained by an absence of /etc/adjtime.

Reco

[toc] | [prev] | [next] | [standalone]

#201228

On Sun 14 Oct 2018 at 17:21:43 +0300, Reco wrote:

> 	Hi.
> 
> On Sun, Oct 14, 2018 at 09:22:53AM -0400, Cindy-Sue Causey wrote:
> > On 10/14/18, tomas@tuxteam.de <tomas@tuxteam.de> wrote:
> > > On Sat, Oct 13, 2018 at 07:11:07AM +0000, Long Wind wrote:
> > >> Thank tomas!
> > >>
> > >> i run "cat /etc/adjtime" in jessie and it says LOCALbut in stretch
> > >> /etc/adjtime doesn't seem to exist
> > >
> > > I see. Perhaps this is the root of the problem. On the other
> > > hand, perhaps, systemd is taking care of time in stretch by
> > > default. In that case I can't help, since my knowledge of
> > > systemd is minimal.
> > 
> > 
> > I was going to bring this up yesterday, just couldn't rope the words
> > in together. With debootstrap, one step the user manually does is
> > this:
> > 
> > +++ QUOTE k/t https://www.debian.org/releases/buster/amd64/apds03.en.html +++
> 
> That guide contains curious relics of the past that include, but aren't
> limited to:
> 
> 1) 'lo' interface in /etc/network/interfaces - unneeded even with
> stretch's ifupdown.

Good catch. It could be omitted or tagged as optional, as broadcast
and gateway are in the following stanza.
 
> 2) 'hostname' record in /etc/hosts - unneeded with libnss-myhostname.

The 127.0.1.1 line? It took us ages to get to this - something which
works.

> 3) '.local' domain at /etc/resolv.conf - a direct violation of RFC 6762.

An example - but a very bad one. Another good catch.

> 4) At controversial (to say the least) recommendation to use 'deb-src'
> of Debian main suite without actually specifying 'deb'.

These are additional examples. Unless I am misunderstanding you, it's
ok.

> 5) The /etc/adjtime configuration itself.
> Systemd defaults to UTC - src/timedate/timedated.c in systemd source
> tree.
> If needed, one can use timedatectl(1) to produce perfectly valid
> /etc/adjtime.

That's correct but I've never experienced the installer not giving a
user an /etc/adjtime.

At present there is an effort to update documentation for buster. Get
your bug report in. Don't delay!

-- 
Brian.

[toc] | [prev] | [next] | [standalone]

#201233

	Hi.

On Sun, Oct 14, 2018 at 07:18:12PM +0100, Brian wrote:
> On Sun 14 Oct 2018 at 17:21:43 +0300, Reco wrote:
> 
> > 	Hi.
> > 
> > On Sun, Oct 14, 2018 at 09:22:53AM -0400, Cindy-Sue Causey wrote:
> > > On 10/14/18, tomas@tuxteam.de <tomas@tuxteam.de> wrote:
> > > > On Sat, Oct 13, 2018 at 07:11:07AM +0000, Long Wind wrote:
> > > >> Thank tomas!
> > > >>
> > > >> i run "cat /etc/adjtime" in jessie and it says LOCALbut in stretch
> > > >> /etc/adjtime doesn't seem to exist
> > > >
> > > > I see. Perhaps this is the root of the problem. On the other
> > > > hand, perhaps, systemd is taking care of time in stretch by
> > > > default. In that case I can't help, since my knowledge of
> > > > systemd is minimal.
> > > 
> > > 
> > > I was going to bring this up yesterday, just couldn't rope the words
> > > in together. With debootstrap, one step the user manually does is
> > > this:
> > > 
> > > +++ QUOTE k/t https://www.debian.org/releases/buster/amd64/apds03.en.html +++
> > 
> > That guide contains curious relics of the past that include, but aren't
> > limited to:
>  
> > 2) 'hostname' record in /etc/hosts - unneeded with libnss-myhostname.
> 
> The 127.0.1.1 line? It took us ages to get to this - something which
> works.

Yup, that very line. It's wrong either way:

a) In the absence of libnss-myhostname own hostname does not correspond
to ::1 (ipv6 loopback). Can lead to some interesting side effects.
b) In the presence of libnss-myhostname that line does not come into
play.
c) FQDN, anyone?


> > 3) '.local' domain at /etc/resolv.conf - a direct violation of RFC 6762.
> 
> An example - but a very bad one. Another good catch.
> 
> > 4) At controversial (to say the least) recommendation to use 'deb-src'
> > of Debian main suite without actually specifying 'deb'.
> 
> These are additional examples. Unless I am misunderstanding you, it's
> ok.

I cannot read :) It does clearly say that 'Debootstrap will have created
a very basic /etc/apt/sources.list that will allow installing additional
packages'.


> > 5) The /etc/adjtime configuration itself.
> > Systemd defaults to UTC - src/timedate/timedated.c in systemd source
> > tree.
> > If needed, one can use timedatectl(1) to produce perfectly valid
> > /etc/adjtime.
> 
> That's correct but I've never experienced the installer not giving a
> user an /etc/adjtime.

Not a Debian per se, but Raspbian lives happily without it.


> At present there is an effort to update documentation for buster. Get
> your bug report in. Don't delay!

I'll consider your suggestion.

Reco

[toc] | [prev] | [next] | [standalone]

#201234

On Sun 14 Oct 2018 at 21:29:57 +0300, Reco wrote:

> On Sun, Oct 14, 2018 at 07:18:12PM +0100, Brian wrote:
> 
> > At present there is an effort to update documentation for buster. Get
> > your bug report in. Don't delay!
> 
> I'll consider your suggestion.

Striking. Iron. Hot.

#911020.

-- 
Brian.

[toc] | [prev] | [next] | [standalone]

#201187

[Multipart message — attachments visible in raw view] — view raw

Long Wind [2018-10-12 21:59:40Z] wrote:

> jessie and stretch are installed on same PCtime of jessie is wrong:
> Fri Oct 12 21:51:05 CST 2018then i reboot and enter stretch time of
> stretch is right: Sat Oct 13 05:55:30 CST 2018 tzdata of both are
> reconfig to same place

As others have pointed out probably one operating system thinks that the
hardware clock is in UTC time and other thinks the clock is in local
time.

You can check and configure this with "timedatectl" command. Running the
command without parameters will show the current status. Command
"timedatectl set-local-rtc [...]" (executed as root user) sets the
option in question. Command's man page tells more.

-- 
/// Teemu Likonen   - .-..   <https://keybase.io/tlikonen> //
// PGP: 4E10 55DC 84E9 DFF6 13D7 8557 719D 69D3 2453 9450 ///

[toc] | [prev] | [next] | [standalone]

#201188 — (solved) Re: jessie and stretch time problem

[Multipart message — attachments visible in raw view] — view raw

Thank Teemu Likonen!
You are right. My stretch and jessie think differently about hardware clock. i run "timedatectl set-local-rtc 1", it should be ok for both now.
though there's warning, i think it's ok
 

    On Saturday, October 13, 2018 3:10 PM, Teemu Likonen <tlikonen@iki.fi> wrote:
 

 Long Wind [2018-10-12 21:59:40Z] wrote:

> jessie and stretch are installed on same PCtime of jessie is wrong:
> Fri Oct 12 21:51:05 CST 2018then i reboot and enter stretch time of
> stretch is right: Sat Oct 13 05:55:30 CST 2018 tzdata of both are
> reconfig to same place

As others have pointed out probably one operating system thinks that the
hardware clock is in UTC time and other thinks the clock is in local
time.

You can check and configure this with "timedatectl" command. Running the
command without parameters will show the current status. Command
"timedatectl set-local-rtc [...]" (executed as root user) sets the
option in question. Command's man page tells more.

-- 
/// Teemu Likonen  - .-..  <https://keybase.io/tlikonen> //
// PGP: 4E10 55DC 84E9 DFF6 13D7 8557 719D 69D3 2453 9450 ///

   

[toc] | [prev] | [next] | [standalone]

#201195 — Re: (solved) Re: jessie and stretch time problem

On Sat 13 Oct 2018 at 07:27:57 (+0000), Long Wind wrote:
> Thank Teemu Likonen!
> You are right. My stretch and jessie think differently about hardware clock.
> i run "timedatectl set-local-rtc 1", it should be ok for both now.
> though there's warning, i think it's ok

Because China doesn't use Daylight Savings Time nowadays, your choice
between UTC and local time is less important than for most as your
clock doesn't have to be changed twice a year.

For everyone else, it makes a lot more sense to use UTC for the real
time clock. Also, judging by my experience on this dual-booting
system (W10 and Debian), up-to-date Windows systems can handle
hardware clocks set to UTC (just as we can cope with your emails
being timestamped with UTC!).

If you apply the same logic to any devices you have that are unaware
of timezones (like many cameras) and set them to UTC, then it will
help with keeping all the file timestamps correct as well. This avoids
having to work out all the ramifications spelled out by pages like

https://msdn.microsoft.com/en-us/library/windows/desktop/ms724290(v=vs.85).aspx
https://msdn.microsoft.com/en-us/library/windows/desktop/ms724290\(v=vs.85\).aspx

>     On Saturday, October 13, 2018 3:10 PM, Teemu Likonen <tlikonen@iki.fi> wrote:
>  Long Wind [2018-10-12 21:59:40Z] wrote:
> 
> > jessie and stretch are installed on same PCtime of jessie is wrong:
> > Fri Oct 12 21:51:05 CST 2018then i reboot and enter stretch time of
> > stretch is right: Sat Oct 13 05:55:30 CST 2018 tzdata of both are
> > reconfig to same place
> 
> As others have pointed out probably one operating system thinks that the
> hardware clock is in UTC time and other thinks the clock is in local
> time.
> 
> You can check and configure this with "timedatectl" command. Running the
> command without parameters will show the current status. Command
> "timedatectl set-local-rtc [...]" (executed as root user) sets the
> option in question. Command's man page tells more.

Cheers,
David.

[toc] | [prev] | [next] | [standalone]

#201198 — Re: (solved) Re: jessie and stretch time problem

On Sat 13 Oct 2018 at 09:03:44 -0500, David Wright wrote:

> On Sat 13 Oct 2018 at 07:27:57 (+0000), Long Wind wrote:
> > Thank Teemu Likonen!
> > You are right. My stretch and jessie think differently about hardware clock.
> > i run "timedatectl set-local-rtc 1", it should be ok for both now.
> > though there's warning, i think it's ok
> 
> Because China doesn't use Daylight Savings Time nowadays, your choice
> between UTC and local time is less important than for most as your
> clock doesn't have to be changed twice a year.

Never knew this, I hope DST and China come up in a pub quiz!
 
> For everyone else, it makes a lot more sense to use UTC for the real
> time clock. Also, judging by my experience on this dual-booting

For Debian (all we care about), UTC time set in the bios is the way to
go. Its always worked for me.

-- 
Brian.

[toc] | [prev] | [next] | [standalone]

#201199 — Re: (solved) Re: jessie and stretch time problem

On 2018-10-13, Brian <ad44@cityscape.co.uk> wrote:
> On Sat 13 Oct 2018 at 09:03:44 -0500, David Wright wrote:
>
>> On Sat 13 Oct 2018 at 07:27:57 (+0000), Long Wind wrote:
>> > Thank Teemu Likonen!
>> > You are right. My stretch and jessie think differently about hardware clock.
>> > i run "timedatectl set-local-rtc 1", it should be ok for both now.
>> > though there's warning, i think it's ok
>> 
>> Because China doesn't use Daylight Savings Time nowadays, your choice
>> between UTC and local time is less important than for most as your
>> clock doesn't have to be changed twice a year.
>
> Never knew this, I hope DST and China come up in a pub quiz!
  
Me neither. What surprised me, though, is that China has no time zones,
either (though it covers over 60 degrees of longitude).

UTC+8 everywhere.

Apparently Mao made the decision in 1949 to put everyone on Beijing
Time (and into those cunning little tunics).

>> For everyone else, it makes a lot more sense to use UTC for the real
>> time clock. Also, judging by my experience on this dual-booting
>
> For Debian (all we care about), UTC time set in the bios is the way to
> go. Its always worked for me.
>


-- 
"Now she understood that Anna could not have been in lilac, and that her charm
was just that she always stood out against her attire, that her dress could
never be noticeable on her." Leo Tolstoy, Anna Karenina 

[toc] | [prev] | [next] | [standalone]

#201200 — Re: (solved) Re: jessie and stretch time problem

On Sat 13 Oct 2018 at 19:51:07 (+0000), Curt wrote:
> On 2018-10-13, Brian <ad44@cityscape.co.uk> wrote:
> > On Sat 13 Oct 2018 at 09:03:44 -0500, David Wright wrote:
> >> On Sat 13 Oct 2018 at 07:27:57 (+0000), Long Wind wrote:
> >> > Thank Teemu Likonen!
> >> > You are right. My stretch and jessie think differently about hardware clock.
> >> > i run "timedatectl set-local-rtc 1", it should be ok for both now.
> >> > though there's warning, i think it's ok
> >> 
> >> Because China doesn't use Daylight Savings Time nowadays, your choice
> >> between UTC and local time is less important than for most as your
> >> clock doesn't have to be changed twice a year.
> >
> > Never knew this, I hope DST and China come up in a pub quiz!
>   
> Me neither. What surprised me, though, is that China has no time zones,
> either (though it covers over 60 degrees of longitude).
> 
> UTC+8 everywhere.
> 
> Apparently Mao made the decision in 1949 to put everyone on Beijing
> Time (and into those cunning little tunics).

That's easy to do when all the power comes from one central authority.
In the USA, virtually the only nationwide rule is that if you want
to change the clocks at all, it has to be done on the same fixed dates.
Timezones, however, are really messy, partly caused, I believe, by the
problem of cities that straddle states in different timezones. I don't
know whether there are any individual counties that are split between zones.

> >> For everyone else, it makes a lot more sense to use UTC for the real
> >> time clock. Also, judging by my experience on this dual-booting
> >
> > For Debian (all we care about), UTC time set in the bios is the way to
> > go. Its always worked for me.

Same here. I used to run DOS on GMT, and had a switch in my programs
that added the hour to any time displayed. As for windows, I stopped
using it in the '90s, but I curate W10 on this PC, and it works
happily on UTC as MS seem to have fixed things.

Cheers,
David.

[toc] | [prev] | [standalone]

Back to top | Article view | linux.debian.user

csiph-web