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.
Topic: Warning: Please check that the computer's date and time... 0.8.2 Client (Read 5559 times)
September 24, 2013, 02:31:07 AM
July 03, 2013, 07:01:45 AM
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.
June 18, 2013, 11:46:53 PM
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.
June 18, 2013, 12:21:12 PM
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 
. June 18, 2013, 12:14:23 PM
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. June 18, 2013, 11:53:03 AM
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. June 18, 2013, 11:30:33 AM
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
June 18, 2013, 11:19:06 AM
there's definitely something wrong with your computer. Here are my timesamples:
I'm guessing you're getting trolled by every peer you're connected to, or your system clock is malfunctioning.
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:
and not this:
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. 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.
June 18, 2013, 09:40:33 AM
Why is the line this:
and not this:
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.
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.
June 18, 2013, 09:12:43 AM
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
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.
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
Quote
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)
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.
June 17, 2013, 10:32:18 AM
I currently have 20 connections. I did the -debug=1 switch and looked in the logs and though I didn't understand everything in them, I did not see anything that would indicated a different time than local. Your thoughts about a router or server up line from my computer having a wrong time is plausible if this problem occurred on other computer within my LAN or within the VMs on the same computer. My Litecoin wallet on the same computer doesn't have a problem with the time, and from what I know, the two wallets have almost identical code.
here's what you should be looking for:Code:
if (fDebug) {
BOOST_FOREACH(int64 n, vSorted)
printf("%+"PRI64d" ", n);
printf("| ");
}
printf("nTimeOffset = %+"PRI64d" (%+"PRI64d" minutes)\n", nTimeOffset, nTimeOffset/60);
BOOST_FOREACH(int64 n, vSorted)
printf("%+"PRI64d" ", n);
printf("| ");
}
printf("nTimeOffset = %+"PRI64d" (%+"PRI64d" minutes)\n", nTimeOffset, nTimeOffset/60);
nTimeOffset = +0 (+0 minutes)"
...but what does this mean?
June 17, 2013, 08:51:42 AM
I currently have 20 connections. I did the -debug=1 switch and looked in the logs and though I didn't understand everything in them, I did not see anything that would indicated a different time than local. Your thoughts about a router or server up line from my computer having a wrong time is plausible if this problem occurred on other computer within my LAN or within the VMs on the same computer. My Litecoin wallet on the same computer doesn't have a problem with the time, and from what I know, the two wallets have almost identical code.
here's what you should be looking for:Code:
if (fDebug) {
BOOST_FOREACH(int64 n, vSorted)
printf("%+"PRI64d" ", n);
printf("| ");
}
printf("nTimeOffset = %+"PRI64d" (%+"PRI64d" minutes)\n", nTimeOffset, nTimeOffset/60);
BOOST_FOREACH(int64 n, vSorted)
printf("%+"PRI64d" ", n);
printf("| ");
}
printf("nTimeOffset = %+"PRI64d" (%+"PRI64d" minutes)\n", nTimeOffset, nTimeOffset/60);
June 17, 2013, 07:11:13 AM
... That is horrible code if it depends on any user-set times... then goes so far to tell you that you are wrong... Well, if it is wrong, then fix it for me, or ignore it, or stop looking at it... Stupid program. lol.
I can't agree with you more here, except for one change. Programs cannot be stupid. They will always simply be a reflection of the programmer(s). That, however, will have to be discussion for a different thread.I currently have 20 connections. I did the -debug=1 switch and looked in the logs and though I didn't understand everything in them, I did not see anything that would indicated a different time than local. Your thoughts about a router or server up line from my computer having a wrong time is plausible if this problem occurred on other computer within my LAN or within the VMs on the same computer. My Litecoin wallet on the same computer doesn't have a problem with the time, and from what I know, the two wallets have almost identical code.
Later today, I'm going to backup my wallet.dat and then blow the whole bitcoin data directory away and uninstall. I'll let y'all know the outcome when I get it all running again.
June 16, 2013, 10:34:45 PM
could it be that you are just connecting to an "off-time" computer... (Some fast hubs report things like "location NewYork", though you are net-fast and through a fiber-hub in "California". Thus, it might be "assuming" your IP is in another timezone that doesn't match the one on your computer. Irrelevant to your actual connection.)
You would have to do a reverse DNS look-up of "what it thinks your IP" actually is. (As some blocks are/were once locked to specific areas, but have been recently "released" for resale since they started using IPV6, or you may be going through an IPV6->IPV4 or IPV4->IPV6 external "router" on your network. Which I think can also be detected, but not avoided in all instances.)
One way to find-out.... is to change your time/date to another time zone, and another... and another.. until you find the one it "Thinks" you are in.
Time is irrelevant on the net... Pings should be the time-adjustment to any single computer that is "asking for a sync". Dates should never be trusted. Stuff gets there, when it gets there. No matter the time. That is horrible code if it depends on any user-set times... then goes so far to tell you that you are wrong... Well, if it is wrong, the fix it for me, or ignore it, or stop looking at it... Stupid program. lol.
You would have to do a reverse DNS look-up of "what it thinks your IP" actually is. (As some blocks are/were once locked to specific areas, but have been recently "released" for resale since they started using IPV6, or you may be going through an IPV6->IPV4 or IPV4->IPV6 external "router" on your network. Which I think can also be detected, but not avoided in all instances.)
One way to find-out.... is to change your time/date to another time zone, and another... and another.. until you find the one it "Thinks" you are in.
Time is irrelevant on the net... Pings should be the time-adjustment to any single computer that is "asking for a sync". Dates should never be trusted. Stuff gets there, when it gets there. No matter the time. That is horrible code if it depends on any user-set times... then goes so far to tell you that you are wrong... Well, if it is wrong, the fix it for me, or ignore it, or stop looking at it... Stupid program. lol.
June 16, 2013, 09:29:53 PM
How many connections to the network is your client showing?
June 16, 2013, 09:18:43 AM
I've tried everything to correct the date/time on my machine and I don't think this has anything to do with the problem. This morning I tried changing my CMOS and Windows date/time back a couple of weeks, rebooted to make sure everything was saved, changed the settings back to the correct date/time and still have the warning. Then I remembered I had a couple of VMware OS's installed for testing, so I cranked them up. Now, these VM boxes should be reading the same system date/time as my main wallet, but the VMs on the same computer don't give the date/time warning. Weird!
So far it seems harmless but I hate mysteries. Especially when money is involved.
if you have "-debug=1" flag enabled, you can check what the time difference is in the logs. then you can correct your system time accordingly. So far it seems harmless but I hate mysteries. Especially when money is involved.
June 16, 2013, 07:27:09 AM
i had this before after having the battery out of a laptop for a while, had to change time and date in the bios
June 16, 2013, 07:25:30 AM
I've tried everything to correct the date/time on my machine and I don't think this has anything to do with the problem. This morning I tried changing my CMOS and Windows date/time back a couple of weeks, rebooted to make sure everything was saved, changed the settings back to the correct date/time and still have the warning. Then I remembered I had a couple of VMware OS's installed for testing, so I cranked them up. Now, these VM boxes should be reading the same system date/time as my main wallet, but the VMs on the same computer don't give the date/time warning. Weird!
So far it seems harmless but I hate mysteries. Especially when money is involved.
So far it seems harmless but I hate mysteries. Especially when money is involved.
June 14, 2013, 12:17:35 PM
Yes.
If nOffset is 0 then fMatch is false and we get a warning.
No but check a few lines above that. It's a BOOST_FOREACH. Therefore, at least 1 peer has to have time in the open interval of (0, 5 minutes) for the warning not to trigger. Also, if you examine the outter if statement, you'll see a check of "if (abs64(nMedian) < 70 * 60)", Which means the check only triggers when that's false. If nOffset is 0 then fMatch is false and we get a warning.
June 14, 2013, 11:49:22 AM
check the next line. If fMatch is false, then the warning triggers.
Yes.If nOffset is 0 then fMatch is false and we get a warning.
June 13, 2013, 03:35:04 PM
check the next line. If fMatch is false, then the warning triggers.
June 13, 2013, 10:51:06 AM
Code:
// If nobody has a time different than ours but within 5 minutes of ours, give a warning
bool fMatch = false;
BOOST_FOREACH(int64 nOffset, vSorted)
if (nOffset != 0 && abs64(nOffset) < 5 * 60)
fMatch = true;
This doesn't make sense to me.bool fMatch = false;
BOOST_FOREACH(int64 nOffset, vSorted)
if (nOffset != 0 && abs64(nOffset) < 5 * 60)
fMatch = true;
Give a warning if the time offset is 0 ?
June 12, 2013, 04:42:38 PM
Have you tried manually synchronizing your time with window's time servers? If you fail to synchronize with windows time, it means there's an issue. In some cases, your computer time may appear to be correct, but your timezone is set incorrectly, resulting in incorrect time.
All good guesses. Checked the timezone is set correctly for Utah and it sync'd just fine to the server. Still have the message. I have a file synchronizer program I wrote a few years ago and if there was anything wrong with my systems date/time it would be barfing up 10 thousand files, but it is working fine. Maybe it's time I pulled in the bitcoin source and started becoming a power-user myself.
check the source for the warning: src/util.cpp
so either:
a) every peer you're connected to is trolling you
or
b) your system time isn't correct.
June 12, 2013, 03:23:30 PM
Have you tried manually synchronizing your time with window's time servers? If you fail to synchronize with windows time, it means there's an issue. In some cases, your computer time may appear to be correct, but your timezone is set incorrectly, resulting in incorrect time.
All good guesses. Checked the timezone is set correctly for Utah and it sync'd just fine to the server. Still have the message. I have a file synchronizer program I wrote a few years ago and if there was anything wrong with my systems date/time it would be barfing up 10 thousand files, but it is working fine. Maybe it's time I pulled in the bitcoin source and started becoming a power-user myself.
June 12, 2013, 03:05:32 PM
Have you tried manually synchronizing your time with window's time servers? If you fail to synchronize with windows time, it means there's an issue. In some cases, your computer time may appear to be correct, but your timezone is set incorrectly, resulting in incorrect time.
June 12, 2013, 08:23:37 AM
Yes, I did check the year. And I think it started the day after the power went out last Sunday. I've double checked the date and times on both my local DHCP router and my Internet modem. It doesn't appear to be stopping the program, but it is a mystery.
I had this warning on my linux client. It didn't cause any problems though and I think it disappeared after a while. Date was correct in my case too.
June 12, 2013, 07:13:57 AM
Yes, I did check the year. And I think it started the day after the power went out last Sunday. I've double checked the date and times on both my local DHCP router and my Internet modem. It doesn't appear to be stopping the program, but it is a mystery.
June 11, 2013, 11:52:29 PM
I hate to ask this, but have you double-checked that the year was correct?
June 11, 2013, 10:52:55 PM
Has it been there for a while?
June 11, 2013, 10:48:36 PM
I've checked that both my CMOS and Windows 7 date and time are correct, yet I have this warning plastered across my client. Any Ideas?
Jump to: