4

Since yesterday my clock is showing a wrong time.

It is two hours behind on the local time. (This wrong time is UTC, don't know if this is coincidence).

I do have a dual boot with windows, but I don't think that is the problem, because in my config file /etc/default/rcS the entry for UTC is already set to no.

Anyone have an idea?

hwclock from util-linux 2.20.1
Using /dev interface to clock.
Last drift adjustment done at 1396258906 seconds after 1969
Last calibration done at 1396258906 seconds after 1969
Hardware clock is on UTC time
Assuming hardware clock is kept in UTC time.
Waiting for clock tick...
...got clock tick
Time read from Hardware Clock: 2015/07/02 09:10:34
Hw clock time : 2015/07/02 09:10:34 = 1435828234 seconds since 1969
Thu 02 Jul 2015 11:10:34 CEST  -0.516481 seconds
Braiam
  • 67,791
  • 32
  • 179
  • 269
Lu Kas
  • 197
  • 1
    Please add the output of sudo hwclock --debug to your question. This may show several assumptions your system is making about the clock. – Jos Jul 02 '15 at 10:33
  • I've added the output in the comment. Strangely is saying the hardware clock is in UTC... But then also the UTC time is incorrect. And as local time it would also be incorrect, as I am in CET which should be UTC+2 and it is UTC-2... – Lu Kas Jul 02 '15 at 11:16
  • Try tzselect and configure the time according to your location – Sergiy Kolodyazhnyy Jul 02 '15 at 11:25
  • My time zone is correct. So that can't be the problem – Lu Kas Jul 02 '15 at 12:52

4 Answers4

2

Hardware clock is on UTC time

If your hardware clock is using UTC time, the system needs to know it! Change the UTC configuration of the clock in the /etc/default/rcS file to yes. The system will presume your clock is UTC and apply offset accordingly. Of course, your clock should also have the correct time. Once this is set, with hwclock --set --date="02/07/2015 10:21:00" (--date should be provided with the local time, even if the hardware clock use UTC) your system should use the correct time. Now you can use ntp daemon, for example to keep your clock on time.

Braiam
  • 67,791
  • 32
  • 179
  • 269
  • Doesn't seem to change anything. Moreover, seems like the offset is always been done correctly, but the hardware clock is wrong. It is saying it is now 11:15:13 in UT... – Lu Kas Jul 02 '15 at 13:15
  • @LuKas just correct the time in your hardware clock with sudo hwclock --set --date="7/02/2015 09:20:05", for example for your local time. – Braiam Jul 02 '15 at 13:19
  • It doesn't stay. When I do this the hardware clock is changed to the correct (UTC) time. But when I restart, somehow it is back to the two hours earlier... – Lu Kas Jul 02 '15 at 13:42
  • @LuKas include in your question the output of date. – Braiam Jul 02 '15 at 13:44
  • you mean this: "Thu Jul 2 13:59:13 CEST 2015"? – Lu Kas Jul 02 '15 at 13:59
  • @LuKas yes, that says that you are using the Central European Summer Time or UTC+2, is this your time zone? – Braiam Jul 02 '15 at 14:02
  • Yes, indeed. The time zone is correct – Lu Kas Jul 02 '15 at 14:15
  • Ok, I found the problem. I also had to change the System Time to the new time of the hardware clock by doing sudo hwclock -s, because otherwise Ubuntu would overwrite the hardware clock again with the (wrong) System Time. – Lu Kas Jul 06 '15 at 08:43
1

Try sudo ntpdate -u time.nist.gov. ntpd is probably running already on that port so it needs to use a different one. Windows assumes clock is in local time when it updates the clock from ntp. Your Linux is assuming it's in UTC.

Martin Thornton
  • 5,431
  • ntpdate doesn't seem to find a suitable synchronization: "2 Jul 12:57:53 ntpdate[3289]: no server suitable for synchronization found" – Lu Kas Jul 02 '15 at 12:59
  • 1
    See http://askubuntu.com/questions/429306/ntpdate-no-server-suitable-for-synchronization-found It might be your ISP has just started blocking NTP packets. Have you dual-booted before without problems? If so, your NTPD was previously correcting the clock at boot before you could see it, but cannot now. – Martin Thornton Jul 02 '15 at 13:33
  • hmm, strange, it always used to work without problems here. – Lu Kas Jul 02 '15 at 13:58
  • One other possibility. Have you changed any firewall settings on your computer or router? Can you show me the output from sudo ntpdate -d time.nist.gov – Martin Thornton Jul 02 '15 at 14:02
  • 2 Jul 14:16:10 ntpdate[3443]: ntpdate 4.2.6p5@1.2349-o Mon Apr 13 13:39:47 UTC 2015 (1) Looking for host time.nist.gov and service ntp host found : utcnist2.colorado.edu transmit(128.138.141.172) transmit(128.138.141.172) transmit(128.138.141.172) transmit(128.138.141.172) transmit(128.138.141.172) 128.138.141.172: Server dropped: no data server 128.138.141.172, port 123 stratum 0, precision 0, leap 00, trust 000 refid [128.138.141.172], delay 0.00000, dispersion 64.00000 transmitted 4, in filter 4 – Lu Kas Jul 02 '15 at 14:18
  • continued: `reference time: 00000000.00000000 Mon, Jan 1 1900 0:00:00.000 originate timestamp: 00000000.00000000 Mon, Jan 1 1900 0:00:00.000 transmit timestamp: d93faa11.5c96aefa Thu, Jul 2 2015 14:16:17.361 filter delay: 0.00000 0.00000 0.00000 0.00000 0.00000 0.00000 0.00000 0.00000 filter offset: 0.000000 0.000000 0.000000 0.000000 0.000000 0.000000 0.000000 0.000000 delay 0.00000, dispersion 64.00000 offset 0.000000

    2 Jul 14:16:19 ntpdate[3443]: no server suitable for synchronization found`

     – Lu Kas Jul 02 '15 at 14:19
  • Ai, no returns in the comments of course – Lu Kas Jul 02 '15 at 14:19
  • Yes, it's an issue with your firewall or ISP. The server cannot see your transmission, or you cannot see its response. – Martin Thornton Jul 02 '15 at 14:34
  • Just to be certain it is also affecting ntpd, what is your output from ntpq -p? – Martin Thornton Jul 02 '15 at 15:16
  • ` remote refid st t when poll reach delay offset jitter

    ssh2.ulyssis.st .INIT. 16 u - 1024 0 0.000 0.000 0.000 rumst.verbert.b .INIT. 16 u - 1024 0 0.000 0.000 0.000 hades.boxed-it. .INIT. 16 u - 1024 0 0.000 0.000 0.000 host-85-201-95- .INIT. 16 u - 1024 0 0.000 0.000 0.000 golem.canonical .INIT. 16 u - 1024 0 0.000 0.000 0.000`

     – Lu Kas Jul 02 '15 at 15:26
  • Yes, ntpd is affected too. It isn't able to see responses from any of its normal servers. Since you said 'it used to work without problems', either your computer or local network firewall, or ISP has recently started blocking NTP packets. – Martin Thornton Jul 02 '15 at 15:40
0

Ok, for future reference, here is the final solution (with some help from the other answers).

The problem was that the hardware clock was wrong, and that apparently due to firewall issues the ubuntu clock can't update automatically. The time of the hardware clock can be changed, either manually by doing

sudo hwclock --set --date="02/07/2015 10:21:00"

for example (with date in local time), or by connecting to time keeping servers online (which didn't work for me because of the firewall issues)

sudo ntpdate -u time.nist.gov

Then the System Time of the Ubuntu kernel still has to be updated to this new time, otherwise the time shown will still be wrong, and, more importantly, Ubuntu will overwrite the new hardware time again. This is easily done with

sudo hwclock -s
Lu Kas
  • 197
-1

First check you have corretc time zone, run the command:

sudo dpkg-reconfigure tzdata

if tzdata is not installed:

sudo apt-get install tzdata

You can now sync and correct your time settings with command ntpdate:

sudo ntpdate time.nist.gov

here you can find a list of time servers around world : http://www.pool.ntp.org/

Check this answer https://askubuntu.com/a/641160/150504 for more information

Community
  • 1
Maythux
  • 84,289