[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: strange time problem with bullseye



On Wed, Mar 06, 2024 at 02:47:06AM +0800, hlyg wrote:
> my newly-installed deb11 for amd64 shows wrong time,  it lags behind correct
> time by 8 hours though difference between universal and local is ok.

Run the commands "date" and "date -u" and show us the output.

Then tell us what you think the output should have been.

> but my deb11 for i386 on same machine shows correct time. i installed it
> long time ago

You have more than one operating system on this machine, then.  Are these
two Debian instances the *only* systems, or are there others?  Is Windows
one of them?

When multi-booting, it's important that all of the operating systems on
the machine agree on whether the real time clock is set to UTC, or to
local time.  For a long time, the conventional approach was to use local
time if you had to multi-boot with Windows (because Windows insisted on
it), or UTC if you only boot Linux-based systems.  I don't know how
Windows deals with the real time clock in modern times.

For comparison, please run "date" and "date -u" on the "deb11 for i386"
instance.

In particular, you're looking to see whether the "date -u" command
reports correct UTC time, and you're looking for what time zone the "date"
command uses.

If your UTC time is right but your time zone is wrong, then you need to
change your time zone.  On Debian, you do this by running
"dpkg-reconfigure tzdata".

If your UTC time is wrong, but it's off by exactly the amount that your
local time differs from UTC, then it's possible that one or more of your
multi-boot operating systems disagree on whether the real time clock is
set to UTC or local time.  Pick one, and then configure all of your
operating systems to use that.

If your UTC time is just wrong, with no obvious reason for it, then the
next question is whether you're running NTP.  And if not, why not (e.g.
this machine is on an isolated network or something).  Most computers
should be using NTP (Debian offers several choices for this), which will
keep the system clock reasonably correct, unless the hardware is failing.


Reply to: