views:

319

answers:

10

Using the timestamp of PHP's time() function, I show the current time to the user with date().

Format: H:i => 13:57

But sometimes there seem to be leaps in time. My windows clock was showing 13:40 when I visited the page. But my website said 14:XX. I don't know the exact time any more.

Another example: A user accessed the page "Who is online?" at 00:16. A user was listed with the time for his last action being 00:39. The last action time is written to the database on every page load. So the time() function must have given back 00:39 at 00:16 and the wrong value must have been written to the database.

How could this happen?

Thank you very much for your help :)

Edit #1 I've reduced my code to the parts which are important for this problem:

I save the timestamp to a new variable with $tStamp = time() in serverData.php and this file is included in index.php where I show the time to the user with date('d.m.Y, H:i', $tStamp). The variable $tStamp isn't changed in any other line.

Edit #2 Users on my website noticed a wrong time on 2010-01-21 00:16 where the page showed 00:39 for a very short moment. I've had a look into the log files and around this time there's one complete hour missing in the logfiles:

127.0.0.1 - - [20/Jan/2010:23:34:53 +0100] ...

127.0.0.1 - - [20/Jan/2010:23:34:55 +0100] ...

127.0.0.1 - - [21/Jan/2010:00:38:41 +0100] ...

127.0.0.1 - - [21/Jan/2010:00:38:41 +0100] ...

My hoster announced maintenance work for 2010-01-20 00:00-06:00. Do you think that the maintenance was set back? Could it be the case that the maintenance work was done on the next day in this time period? Could such a work make the time wrong?

Edit #3 Finally, I have an answer from my hoster :) In the given period of time, the server crashed. And because of that the watch/clock stopped. It was that simple but I didn't think of a server crash. Thank all of you very much!

+2  A: 

Remember that time() returns the server time not yours. If it returns a different value it means that the server time is different from your pc time.

mck89
No! You've misunderstood something. The time jumps to a wrong value for a while. After a few seconds the correct time was shown again. And if my pc time and the server time match, they should still match in 5 minutes, right? ;)
NTP-server (I.e. time) synchronization problem?Does this occur on another machine for instance?
lungic
I've hosted this project on a shared hosting. So I've just this webspace and no other servers.
"if my pc time and the server time match, they should still match in 5 minutes, right?"... Sounds funny, but there is no guarantee at all. Heck, even the wall clock in my kitchen drifts, and sometimes I adjust it. The NTP-server is a good hint.
xtofl
No, the time isn't gradually drifting, it just skips out for a short time and then it is correct again.
A: 

You can configure your server's time zone in php.ini or at runtime with the date_default_timezone_set() function.

Johannes Gorset
I already do this: date_default_timezone_set('Europe/Berlin')
do you process the value returned from time() in any way prior to inserting it into the database?
Johannes Gorset
Yes, I've added some details in my question after "Edit #1". Does this help?
A: 

There is possibly an error in your code. Please paste some code if you can.

Otherwise create a few test pages where you reduce the problem to a simpler code base and just test the time functions. This will help clarify and isolate any potential problems. Do you understand what I mean?

Antony Carthy
Thank you! I've added a few more details with code after "Edit #1" in my question. Does it help?
+2  A: 

As a really far out option, there could be a bad ntp location that is temporarily changing the system time when it is checked against. It would be set back to the correct time on the next update to a correct server. I don't think a system time would be likely to drift that much.

Cryophallion
When is it updated again? My problem occurs very rarely and always just for a few seconds. So could it be the bad ntp location?
I would check the crontab files and the ntp server pool. Do you have access to this info on the servers?
Cryophallion
Can you also create a file that will log the current time, to see how frequently it drifts, and whether the drift is consistent (i.e., exactly 4 minutes, and it happens every 5 hours)? That would likely give you a more exact glimpse into the issue.
Cryophallion
Finally, does the problem still happen if you call to time() instead of the variable in your index.php? I could see it jumping back if it isn't ntp (as it could be a cached value), but jumping forward is just odd.
Cryophallion
Fascinating - I give an answer almost two weeks ago, and the guy who answers yesterday with the same comment gets all the up-votes. Anyway, any luck with the logging? I'm curious as to whether you were able to fix the issue.
Cryophallion
Thank you very much for your answer and the comments :) How would you do the logging? Add a cron job which writes the current timestamp to the database every 5 minutes with an auto-increment id? So you could check if sequent timestamp entries are always greater than the one before. This way?
That would be where I would start, yes.Edit two brings up the another possibility - a failover server.If they took down your existing server for maintenance, then they may have switched you over to another server, and this one may have the time set wrong. The 23 minutes off is just odd. The hour of missing log files could be because the normal server was down for that time period.Have you tried talking to your hosting company, and getting up a few levels in the support chain to see where you were moved around to at that time?
Cryophallion
Actually, I would to the cron job (or even a php script) to do the following:every minute, write the current time to a database table (for even more interesting results, have another column for mysql's timestamp). Then, write a foreach to parse the db to see if the current row is greater than or 2 minutes away from the previous value in either direction, then echo just those results. That will give you the start and end times for each event.Once you have that info (and can additionally check if the mysql server has the same hiccup), you can see if it is consistent, and chat with the hoster.
Cryophallion
Thank you very much for your detailed comments! I've started logging what you wrote in the last comment. Your explanation in the comment before sounds plausible. Probably it was like that.
+1  A: 

This could be a caching issue compounded by a server set to another time zone—one hour ahead would seem most likely for the examples.

Turn off the browser's cache, and if the server has a cache (squid, etc.), turn that off as well, and retry the experiment.

Either that, or a server farm has a node or two with an incorrectly set time.

wallyk
I don't think it could be a caching issue. If it was caused by caching, the wrong time would date back. But in my case it dates forward, the wrong time is in the future. Don't you think so?
An examination of timestamps in the server logs would be most interesting.
wallyk
I've posted some lines of the server logs in my Edit #2 in the question above. Does that help?
Only 4 timestamps? Do you have any coinciding with when the anomaly occurs?
wallyk
When the anomaly occured, there is something missing in the logfiles. A complete hour isn't listed in the log. So I posted the two timestamps before and after the anomaly.
A: 

I would propose to compare script output with apache log, or even better - to also create a log which would write down the time value when it's requested. This is to exclude the following possibility:

Some of the providers have caching networks that do not deliver the content directly from you to the site, but cache it instead, in hope somebody else would also ask for the same page and then they can save outside bandwidth. So you might be getting a wrong version of the page if there's some glitch in this network.

Comparing with apache log or syslog would help you see if other code has the same idea of the time as your code - which eliminates the possibility of it being code problem and probably takes it out of the php realm into the server realm. If it is so, I would look closely into ntp - it's the only daemon I know that is supposed to mess with time.

StasM
What do you think about the server logs I've posted in Edit #2 in the question above? Could this be the cause?
A: 

The method is to get the time of your server by PHP and inject into client side javascript, converting it to GMT time and adding the offset thus transforming the time to that of your time zone. See this for more info.

Sarfraz
+8  A: 

Having read all of this question and your responses in comments, I can say that the chances of this being a bug in PHP are pretty infinitesimal. PHP's time() pulls directly from the OS, which pulls directly from the hardware clock on the mainboard. Since you're on shared hosting, you're going to have to ask your host to look into it if this is happening often enough to be a problem. It could be a rogue NTP server or process, it could be some sort of short in the hardware clock — without access to the server logs or physical access to the computer, there's not a whole lot that you can do personally that I know of.

Brock Batsell
Thank you very much! So to sum everything up: It is probably caused by the server not by PHP and I need access to the server to find out the cause. Is this correct?
That certainly appears to be the case, absolutely. Thoroughly document it whenever it happens again so that your host has something to work with.
Brock Batsell
Thanks, I'll ask my hoster. Please see my Edit #2. What do you think about it?
Maintenance around the time of a leap could indicate that the server's time had drifted, which they discovered and rectified (or at least attempted to). That log shows a 64 minute drift, which would be pretty unusual, but not impossible. Or it could be something entirely different — it's pretty hard to tell exactly what the problem is just from these limited symptoms, and I administer quite a few servers every day.
Brock Batsell
A: 

Do you happen to be on a virtual machine? I have seen (I think) VMWare based virtual machines losing as much as a few minutes a day(!) when under stress.

Pekka
In my case the time doesn't lose minutes but it gains minutes!?
@marco92w, it doesn't matter which way. The clock can go weird ways on virtual machines.
Pekka
Hmm ... I don't know if I am on a virtual machine or not. Does the string help which php_uname gives back? => Linux wp029 2.6.30.2-he-xeon-64gb+4 #1 SMP Sat Aug 15 15:25:21 CEST 2009 i686
A: 

A rogue node with an incorrectly set time on a server farm could definitely do this (as suggested by @wallyk) - and this is much more plausible than this being an NTP issue.

See if there is any way of identifying which node your request is serviced by.

Try including php_uname() or gethostname() in an HTML comment and examining the source of the page where the time is incorrect. These might give enough information to determine if the problem is associated with a specific node.

Or create a page which prints the results of the function call along with the current time() and write a script which gets that page multiple times until an anomaly is observed. (Obviously you would be careful to avoid the page being cached, and would first assure yourself that php_uname() or gethostname() gave enough information to determine whether different requests were being handled by different nodes)

MZB
gethostname() isn't available for me since I have PHP version 5.2.12. But php__uname() gives back the following string: Linux wp029 2.6.30.2-he-xeon-64gb+4 #1 SMP Sat Aug 15 15:25:21 CEST 2009 i686 Does this help?