Intoweb
asked on
One server converts epoch time incorrectly
Hi Experts,
We are having a VERY strange problem. One of our linux servers is converting epoch time into date incorrectly. It keeps being one day out.
For instance, 1364508000 converts correctly to 29 March 2013 on all of our servers, which is correct and is good Friday, but on our ONE server it converts to 28 March 2013. This is happening with all epoch stamps. It keeps converting to a day early. We are an office full of PHP developers and we are all stumped. I'm sure that this is problem on the linux server, but our linux administrator is being a little bitch, so now we have to try and fix it ourselves. ANY advice would be greatly appreciated.
Thank you in advance,
The entire Intoweb Team
We are having a VERY strange problem. One of our linux servers is converting epoch time into date incorrectly. It keeps being one day out.
For instance, 1364508000 converts correctly to 29 March 2013 on all of our servers, which is correct and is good Friday, but on our ONE server it converts to 28 March 2013. This is happening with all epoch stamps. It keeps converting to a day early. We are an office full of PHP developers and we are all stumped. I'm sure that this is problem on the linux server, but our linux administrator is being a little bitch, so now we have to try and fix it ourselves. ANY advice would be greatly appreciated.
Thank you in advance,
The entire Intoweb Team
ASKER CERTIFIED SOLUTION
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
Where are you seeing this error?
ASKER
I am getting this error in all my PHP scripts where we run date("Y-m-d", $iTimestamp).
The timezones are correct, although the one was on GMT +2 and the other on UCT +0, but technically it's the same time. We changed them both to GMT +2 and I'm still getting this issue.
I also don't understand how timezone would have an impact on epoch conversion. It's supposed to calculate from 0:00 01/01/1970 regardless of the timezone....
I could understand if date("U") gave different epoch's due to timezone, but once the epoch has been established, how can it be that it calculated the date wrong based on that stamp?
The timezones are correct, although the one was on GMT +2 and the other on UCT +0, but technically it's the same time. We changed them both to GMT +2 and I'm still getting this issue.
I also don't understand how timezone would have an impact on epoch conversion. It's supposed to calculate from 0:00 01/01/1970 regardless of the timezone....
I could understand if date("U") gave different epoch's due to timezone, but once the epoch has been established, how can it be that it calculated the date wrong based on that stamp?
<< I also don't understand how timezone would have an impact on epoch conversion <<
Seconds since epoch are computed relative to the local time be means of the localtime() function call.
The localtime() function converts the calendar time timep to broken-down time representation, expressed relative to the user's specified timezone.
The function acts as if it called tzset(3) and sets the external variables tzname with information about the current timezone, timezone with the difference between Coordinated Universal Time (UTC) and local standard time in seconds, and daylight to a nonzero value if daylight savings time rules apply during some part of the year.
Backwards coversion adheres to the same rule, of course, else you would get different results depending on the direction of the conversion.
Seconds since epoch are computed relative to the local time be means of the localtime() function call.
The localtime() function converts the calendar time timep to broken-down time representation, expressed relative to the user's specified timezone.
The function acts as if it called tzset(3) and sets the external variables tzname with information about the current timezone, timezone with the difference between Coordinated Universal Time (UTC) and local standard time in seconds, and daylight to a nonzero value if daylight savings time rules apply during some part of the year.
Backwards coversion adheres to the same rule, of course, else you would get different results depending on the direction of the conversion.
ASKER
Thanks, that makes sense, I guess. But the localtime and timezones are the same on all our servers, so that it not our problem.
ASKER
I found it. The problem was caused by the timezone, but it was inside php.ini and not the server time itself. Thanks.
That's kind of what I was expecting. One of the oddities about using timezones in PHP is that if you want just the date in a timezone that has "Daylight Savings Time", you need to ask what day it is at noon and not midnight. The DST calculations around midnight will drive you crazy wondering what is going on, especially on the day it changes.
CentOS, RedHat, etc.
sudo ln -sf /usr/share/zoneinfo/Contin
Debian, Ubuntu, etc
sudo dpkg-reconfigure tzdata