Warning: Please check that the computer's date and time... 0.8.2 Client

[Kitemike]

I know what it means now, but...

The more I work with computers (and I've been working with them for 32 years), the more I'm amazed at how intricate and complicated the simplest problems can become.  I was baffled why other clients (litecoin, feathercoin) didn't have the problem with the time. I was confused that my virtual machines didn't have an issue even when set to use the host date/time.  But, after studying the util.cpp till I knew what to look for (thanks for all the suggestions), I was completely blown away when this showed up in the debug.log

Bitcoin version v0.8.2-beta (2013-05-25 08:48:25 -0700)
Using OpenSSL version OpenSSL 1.0.1c 10 May 2012
Startup time: 2013-06-18 13:17:36

Added time data, samples 2, offset -2336471 (-38941 minutes)
Added time data, samples 3, offset -2336471 (-38941 minutes)
Added time data, samples 4, offset -2336471 (-38941 minutes)
Added time data, samples 5, offset -2336471 (-38941 minutes)
*** Warning: Please check that your computer's date and time are correct! If your clock is wrong Bitcoin will not work properly.
nTimeOffset = +0  (+0 minutes)
Added time data, samples 6, offset -2336474 (-38941 minutes)
Added time data, samples 7, offset -2336474 (-38941 minutes)
nTimeOffset = +0  (+0 minutes)
Added time data, samples 8, offset -2336474 (-38941 minutes)
Added time data, samples 9, offset +3 (+0 minutes)
nTimeOffset = +0  (+0 minutes)
Added time data, samples 10, offset +5 (+0 minutes)

This was from a fresh debug.log and all the entries occurred within about 1 minutes of each other.  I've stripped out all the extraneous IP connection and addressing lines.  Note that as it connected to peers, the time difference was quite consistent (aprox. 28 days) until all of a sudden after 9 connections, the difference went to zero, all while consistently showing me the correct date/time on my desktop.  It is consistent that every time I start the bitcoin-qt, the time is off about that much, but whether or not the difference goes away is inconsistent.  

If it was the bios that had the wrong time, it would not straighten itself out randomly without a reboot, and certainly not mess itself up simply by closing the bitcoin client and re-opening it. I have completely uninstalled the client and deleted the %appdata%\bitcoin directory and started over new, yet am right back where I started with only the mystery and few answers.  Something happened or got written someplace around May 20 that the client keeps reading.  What it is, I have no clue.

[1714919016]

1714919016

[1714919016]

1714919016

[1714919016]

1714919016

[1714919016]

1714919016

[kneim]

Why is the line this:

Code:

  if (nOffset != 0 && abs64(nOffset) < 5 * 60)
    fMatch = true;

and not this:

Code:

  if (abs64(nOffset) < 5 * 60)
    fMatch = true;

I believe Schleicher is right. nOffset is in seconds, and it's easy to be under one second by time syncronisation. So if every nOffset is Zero, the second comparison with "abs64(nOffset) < 5 * 60" is never checked.

I cannot explain the output of debug.log.

[grue]

there's definitely something wrong with your computer. Here are my timesamples:

Code:

	Line 90: 2013-06-17 04:01:26 Added time data, samples 103, offset -1 (+0 minutes)
	Line 109: 2013-06-17 04:01:37 Added time data, samples 104, offset -4 (+0 minutes)
	Line 778: 2013-06-17 13:49:29 Added time data, samples 105, offset +3 (+0 minutes)
	Line 786: 2013-06-17 13:49:30 Added time data, samples 106, offset +0 (+0 minutes)
	Line 1092: 2013-06-17 13:50:14 Added time data, samples 107, offset +0 (+0 minutes)
	Line 1099: 2013-06-17 13:50:15 Added time data, samples 108, offset -1 (+0 minutes)
	Line 1105: 2013-06-17 13:50:15 Added time data, samples 109, offset +1 (+0 minutes)
	Line 1125: 2013-06-17 13:50:21 Added time data, samples 110, offset +1 (+0 minutes)
	Line 1131: 2013-06-17 13:50:22 Added time data, samples 111, offset +1 (+0 minutes)
	Line 1138: 2013-06-17 13:50:23 Added time data, samples 112, offset +0 (+0 minutes)
	Line 1152: 2013-06-17 13:50:26 Added time data, samples 113, offset +3 (+0 minutes)
	Line 1637: 2013-06-17 13:57:56 Added time data, samples 114, offset +2 (+0 minutes)
	Line 2047: 2013-06-17 23:27:54 Added time data, samples 2, offset +0 (+0 minutes)
	Line 2052: 2013-06-17 23:27:55 Added time data, samples 3, offset +0 (+0 minutes)
	Line 2116: 2013-06-17 23:28:26 Added time data, samples 4, offset +0 (+0 minutes)
	Line 2174: 2013-06-17 23:28:39 Added time data, samples 5, offset -1 (+0 minutes)
	Line 2185: 2013-06-17 23:28:42 Added time data, samples 6, offset +1 (+0 minutes)
	Line 2245: 2013-06-17 23:28:51 Added time data, samples 7, offset +3 (+0 minutes)
	Line 2402: 2013-06-17 23:29:15 Added time data, samples 8, offset -1 (+0 minutes)
	Line 2405: 2013-06-17 23:29:15 Added time data, samples 9, offset +5 (+0 minutes)
	Line 2473: 2013-06-17 23:29:21 Added time data, samples 10, offset -1 (+0 minutes)
	Line 2595: 2013-06-17 23:29:38 Added time data, samples 11, offset +0 (+0 minutes)
	Line 2638: 2013-06-17 23:29:54 Added time data, samples 12, offset +1 (+0 minutes)
	Line 2687: 2013-06-17 23:30:36 Added time data, samples 13, offset +2 (+0 minutes)
	Line 2755: 2013-06-17 23:31:36 Added time data, samples 14, offset +1 (+0 minutes)
	Line 2826: 2013-06-17 23:33:09 Added time data, samples 15, offset +1 (+0 minutes)
	Line 2860: 2013-06-17 23:33:40 Added time data, samples 16, offset +2 (+0 minutes)
	Line 2865: 2013-06-17 23:33:41 Added time data, samples 17, offset +3 (+0 minutes)
	Line 2945: 2013-06-17 23:35:06 Added time data, samples 18, offset +152 (+2 minutes)
	Line 2997: 2013-06-17 23:36:03 Added time data, samples 19, offset +0 (+0 minutes)
	Line 3033: 2013-06-17 23:36:36 Added time data, samples 20, offset +0 (+0 minutes)
	Line 3367: 2013-06-17 23:41:55 Added time data, samples 21, offset +0 (+0 minutes)
	Line 3730: 2013-06-17 23:48:17 Added time data, samples 22, offset +1 (+0 minutes)
	Line 3851: 2013-06-17 23:50:21 Added time data, samples 23, offset +0 (+0 minutes)
	Line 3867: 2013-06-17 23:50:37 Added time data, samples 24, offset +0 (+0 minutes)
	Line 4319: 2013-06-17 23:54:40 Added time data, samples 25, offset +1 (+0 minutes)
	Line 5037: 2013-06-18 00:01:34 Added time data, samples 26, offset +4 (+0 minutes)
	Line 6266: 2013-06-18 00:09:12 Added time data, samples 27, offset -15 (+0 minutes)
	Line 7156: 2013-06-18 00:14:41 Added time data, samples 28, offset -7 (+0 minutes)
	Line 7173: 2013-06-18 00:14:47 Added time data, samples 29, offset +1 (+0 minutes)
	Line 7321: 2013-06-18 00:16:29 Added time data, samples 30, offset +22 (+0 minutes)
	Line 7712: 2013-06-18 14:26:51 Added time data, samples 2, offset +2 (+0 minutes)
	Line 7762: 2013-06-18 14:27:09 Added time data, samples 3, offset -1 (+0 minutes)
	Line 7764: 2013-06-18 14:27:09 Added time data, samples 4, offset +247 (+4 minutes)
	Line 7767: 2013-06-18 14:27:09 Added time data, samples 5, offset -3 (+0 minutes)
	Line 7776: 2013-06-18 14:27:10 Added time data, samples 6, offset +1 (+0 minutes)
	Line 7840: 2013-06-18 14:27:22 Added time data, samples 7, offset +0 (+0 minutes)
	Line 7913: 2013-06-18 14:27:30 Added time data, samples 8, offset +15 (+0 minutes)
	Line 8057: 2013-06-18 14:27:50 Added time data, samples 9, offset +3 (+0 minutes)
	Line 8069: 2013-06-18 14:27:51 Added time data, samples 10, offset +2 (+0 minutes)
	Line 8109: 2013-06-18 14:27:56 Added time data, samples 11, offset +3 (+0 minutes)
	Line 8229: 2013-06-18 14:28:03 Added time data, samples 12, offset +3 (+0 minutes)

I'm guessing you're getting trolled by every peer you're connected to, or your system clock is malfunctioning.

Why is the line this:

Code:

  if (nOffset != 0 && abs64(nOffset) < 5 * 60)
    fMatch = true;

and not this:

Code:

  if (abs64(nOffset) < 5 * 60)
    fMatch = true;

I believe Schleicher is right. nOffset is in seconds, and it's easy to be under one second by time syncronisation. So if every nOffset is Zero, the second comparison with "abs64(nOffset) < 5 * 60" is never checked.

I cannot explain the output of debug.log.

those lines are only executed if there is a time difference. therefore nOffset can't be zero.

[Kitemike]

Yes, I'm leaning toward motherboard issues also.  It looks like my wife is going to get a pretty robust (though slightly used) gaming machine.  Time for me to go shopping again.  I always get the new computer

[grue]

Yes, I'm leaning toward motherboard issues also.  It looks like my wife is going to get a pretty robust (though slightly used) gaming machine.  Time for me to go shopping again.  I always get the new computer

if the time sample is always off by a consistent amount, try setting the BIOS time forwards/backwards to compensate for it. In your case, try setting it back 38941 minutes.

[Kitemike]

Yes, I'm leaning toward motherboard issues also.  It looks like my wife is going to get a pretty robust (though slightly used) gaming machine.  Time for me to go shopping again.  I always get the new computer

if the time sample is always off by a consistent amount, try setting the BIOS time forwards/backwards to compensate for it. In your case, try setting it back 38941 minutes.

It's not consistent. It appears to be reading a time that is frozen on or about May 20th, but it sometimes only reads it for a couple of random minutes before it finds the correct time somewhere.  Even changing the BIOS way off and back doesn't make the problem go away.  Even when I find the right time on May 20th, within 5 minutes of setting the time, I'm back looking at the message as the world turns under my stuck in time computer.  The only thing that confuses me, is why the bitcoin client is the only program that is reading a bad date/time.  My BIOS is right, my Windows is right. I wrote a little c# program that loops around and displays DateTime.Now and never see anything but the correct time.  It's got to be a hardware issue, but not like anyone I've ever seen before.

[grue]

It's not consistent. It appears to be reading a time that is frozen on or about May 20th, but it sometimes only reads it for a couple of random minutes before it finds the correct time somewhere.  Even changing the BIOS way off and back doesn't make the problem go away.  Even when I find the right time on May 20th, within 5 minutes of setting the time, I'm back looking at the message as the world turns under my stuck in time computer.  The only thing that confuses me, is why the bitcoin client is the only program that is reading a bad date/time.  My BIOS is right, my Windows is right. I wrote a little c# program that loops around and displays DateTime.Now and never see anything but the correct time.  It's got to be a hardware issue, but not like anyone I've ever seen before.

before spending your money on a new computer, you can try a linux live cd to check if the issue is isolated to windows ...or not, if you need a excuse for a gaming machine .

[Maged]

Have you tried using an older Bitcoin version? Many alt-coins live in the past, so that could explain why they work, but Bitcoin doesn't.

[Kitemike]

As a follow-up, it's been a week since the problem mysteriously disappeared.  It is my guess that either my motherboard glitch worked itself out (unlikely) or that a Windows update last week replaced a corrupted file someplace (probably).  Thanks to everyone that made suggestions.

[niko]

I've been running a node literally for years, and never seen this happen... until tonight. I closed the client, replaced wallet.dat with an old backup file, started the client... and the warning appeared!  I was able to send funds from this old wallet normally. I closed the client, placed the original wallet.dat in, and started the client again. The warning is still here!

I did not even reboot the computer. Simply closing and re-opening the client twice is all that happened. Computer time and time zone are correct, just as they have been before this. It's a Windows 7 desktop.