The subject says it all. Posts made at 11:45 am (EST) are shown as having been posted at 11:25 am (EST). A small thing, but annoying.
That’s puzzled me too. I’m on GMT and the time now is just 4.54pm.
To quote from the last time this question came up, please see:
Time keeps slipping, slipping . . .
>http://boards.straightdope.com/sdmb/showthread.php?t=292386
“The technical staff has indicated to me that slippage will happen . . . and they’re not going to do anything about it.”
Apologies for this; it’s those little things like what time is listed that can be the most annoying. The message board staff has no control over this function.
your humble TubaDiva
They’re blowing smoke up where the sun don’t shine. This is a 10-second fix at the console for the server, not some wildly difficult undertaking. Someone might have to put in those taxing 10 seconds once a week or so. No one’s demanding synchronization with the Atomic Clock.
It’s conceivable that they’re not idiots and that there is a good reason that adjusting the clock isn’t quite as trivial as running ‘netdate’. For example, the vBulletin software might have a bug that makes it freak out if the time changes out from under it.
I confess that I never encountered vBulletin in my working years, so you might be right. However, I never, ever ran into a database (and there were some might shaky pieces of database crap running on my servers at various times!) that couldn’t handle having the clock reset, especially not when the clock is slow, and needs to be pushed forward.
And, in this thread on the same subject, TubaDiva indicates that there is no technical impediment to fixing the problem:
I suspect that it has more to do with the way the tech staff prioritizes its work. When faced with, say, 20 tasks, 19 of which are minor, and one of which is a bear, they’ll tackle the big one, and let the little stuff languish. When I was a supervisor, it took some effort for me to retrain my staff to stop doing that. It makes the end users much happier if you pick all the low-hanging fruit first - take care of the little shit, and get it out of the way. Then you can wrestle with the bear. It doesn’t take any more time to do that, since you still end up doing the same 20 tasks.
In any event, it’s not a big deal - just a minor annoyance.
To put some factual knowledge into this thread:
I am part of the admin dept. of hundreds of web servers.
Pushing a clock instantaneously backwards is always a bad idea, that can result in many unpredictable errors. Pushing it forwards almost always can be done with only minor effects, however, there are still issues there, for example what happens to the numerous timeouts that sould have been handled in the now missing time? (And there are lots of such timeouts pending as thousands of TCP/IP connections are involved.)
While technically setting the clock of a server is no more difficult than setting the clock on your PC, it still requires deep knowledge of all the software running on the server, to prevent failures from instantaneous clock changes.
Now, this being a common problem on all heavy loaded servers, there are certainly solutions to it. One favorable solution is a time synchronisation software (usually based on NTP). Such a software can be configured to adjust the clock incrementally and hence preventing instantaneous changes. At least for UNIX I know, that it even can be installed on a running server to take over the clock and resynchronize it slowly. Not sure about a Windows Server though. But still you have to be an expert to install this software on a running system, or else (with default settings) it will just correct the clock instantaneously.
So, the tech guys are well advised, not to simply “change the clock in the control panel”, because it is nothing you should do if you cannot afford to shut down your server even for a second. (If you have no other choice, you will postpone it until the next maintenance time slot. And I think that’s what they do right now.)
However, there is still shed some bad light on the tech guys, because one should ask, why such a time sync software is not already in place. (However, it may be there and malfunctioning. I’ve seen this, once a NTP software insisted on the hardware clock running to slow (but it did not!), and adjusted it to run faster. So fast, that within minutes the clock ran out of the allowed sync window and so NTP stopped managing the clock. It took us days, to determine the cause: defective hardware clock)
All of ours servers get equipped with such a software before we even setup a single HTTP server on them.
cu
I once debugged an NT 4.0 driver for a custom network device that had the exact problem that you mentioned. It would run fine for an hour or so and then Windows would synch the real-time clock with the software clock. All of the protocol timers would expire and all data transfers would stop. Once identified, it was an obvious bug and easy to fix. For this reason I don’t think the TCP/IP timers are based on the software clock. Instead, they use a timer library that is based on timer ticks. It is a more efficient implementation and avoids the problem of a clock change.