• Status: Solved
  • Priority: Medium
  • Security: Public
  • Views: 691
  • Last Modified:

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
0
Intoweb
Asked:
Intoweb
  • 3
  • 2
  • 2
  • +1
1 Solution
 
woolmilkporcCommented:
Check and compare the timezone settings on your servers.

echo $TZ

date +%Z
date +%z
0
 
DanielSVCommented:
If the timezone is wrong, as woolmilkporc suggests, fix it like this.

CentOS, RedHat, etc.
sudo ln -sf /usr/share/zoneinfo/Continent/City /etc/timezone

Debian, Ubuntu, etc
sudo dpkg-reconfigure tzdata
0
 
Dave BaldwinFixer of ProblemsCommented:
Where are you seeing this error?
0
Technology Partners: We Want Your Opinion!

We value your feedback.

Take our survey and automatically be enter to win anyone of the following:
Yeti Cooler, Amazon eGift Card, and Movie eGift Card!

 
IntowebAuthor Commented:
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?
0
 
woolmilkporcCommented:
<< 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.
0
 
IntowebAuthor Commented:
Thanks, that makes sense, I guess. But the localtime and timezones are the same on all our servers, so that it not our problem.
0
 
IntowebAuthor Commented:
I found it. The problem was caused by the timezone, but it was inside php.ini and not the server time itself. Thanks.
0
 
Dave BaldwinFixer of ProblemsCommented:
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.
0

Featured Post

NEW Veeam Backup for Microsoft Office 365 1.5

With Office 365, it’s your data and your responsibility to protect it. NEW Veeam Backup for Microsoft Office 365 eliminates the risk of losing access to your Office 365 data.

  • 3
  • 2
  • 2
  • +1
Tackle projects and never again get stuck behind a technical roadblock.
Join Now