Weird stamp2date problem! (different results)

Tea_J

Hi,

I've been getting different results on my local server and remote server:

Both similars are very similar (apache, php, mysql, etc).. except that the local server here at home is on Windows XP and the remote is unix (in USA)

To simplify my problem for you guys, I have this code:

stamp2date.php

<?php

$b = date("Y-m-d",$_GET['stamp']);

echo "$b";

?>

Obviously, it converts a unix stamp to date in YYYY-MM-DD format..

The weird thing is, sometimes my stamp2date routine produces different results!

Here are the stamps producing different results:

1115017924
LOCAL = MAY 2, 2005
REMOTE = MAY 2, 2005

(They are the same as SHOULD BE)

1112284800
LOCAL = April 01, 2005
REMOTE = March 31, 2005

1113926400
LOCAL = April 20, 2005
REMOTE = April 19, 2005

The last two unix timestamps produces DIFFERENT RESULTS! How come?!

The Remote server seems to be a day late!

I've tried different servers already..same results.

Can ya'll try converting those on your servers??

What could be wrong here?

I was thinking TIMEZONES of the servers.. but those unix timestamp arent TIMEZONE dependent.. They represent a CERTAIN and SPECIFIC DATE based on the seconds passed since epox..

Also, SOME TIME STAMPS produce the same results (Like the first one) and some dont..

im mystified.

tea

Weedpacket

Originally posted by Tea_J
I was thinking TIMEZONES of the servers.. but those unix timestamp arent TIMEZONE dependent.. They represent a CERTAIN and SPECIFIC DATE based on the seconds passed since epox..

The Epoch is 1970-01-01 00:00:00 UTC.

If you're not using gmdate() you're using local time, not UTC.

Try a few experiments to bolster your understanding. Eg:

echo mktime()-gmmktime();

echo date('Y-m-d H:i:s',0);

echo gmdate('Y-m-d H:i:s',0);

Tea_J

hi..

thanks.. i see your point.. i knew about them already but i never thought they would affect me this way.. thanks.. gmdate() worked for me.. BUT.. and it's a big BUT.

What I still dont get is i thought date() calculates the seconds that passed since epoch to the 1112284800 (seconds passed) and present in the date format.. i dont understand its relativeness with the server's timezone...

Here was my dilema:
I needet to set the dates of all profiles in the database to April 1, 2005.

and since my date column was in a 10 integer / epoch time stamp format..

therefore to get that:

mktime(0,0,0,04,01,2005);

resulting in = 1112284800

but here's where my problem probably started......

because executing

mktime(0,0,0,04,01,2005);

results in = 1112313600

Now im confused.. because

mktime() =
"Returns the Unix timestamp corresponding to the arguments given. This timestamp is a long integer containing the number of seconds between the Unix Epoch (January 1 1970) and the time specified. "

based on the above, i dont see why my LOCAL server and Remote server which are in different timezones would produce different results.. i dont see how the SECONDS PASSED since epoch to my SPECIFIED EXACT DATE (April 1, 2005) would be timezone dependent.. basically, SECONDS are UNIVERSAL.

hmm.. im sorry if im starting to sound ignorant here, 😃 but i never encoutered this before and would liek to know more about it.. get the bug out of ma head. 🙂

Regards,

Tea

Weedpacket

date() will produce different date/times for the same timestamp - and mktime() will produce different timestamps for the same date/time - for machines in different timezones; both functions use the timezone of the machine running them. That is why gmdate() and gmmktime() were written.

Originally posted by Tea_J
i dont see how the SECONDS PASSED since epoch to my SPECIFIED EXACT DATE (April 1, 2005) would be timezone dependent.. basically, SECONDS are UNIVERSAL.

What time on April 1, 2005? There were 86400 seconds during that day, and 86400 timestamps. The one you specified was for 2005-04-01 00:00:00 in the timezone of whatever server generated it - eight hours ahead of UTC.

Tea_J

hmm.. i see. well i still got some cobwebs in ma head bout this, but i can manage from here..

thanks man!

so... is it alrite to say that it is recommended to always use gmdate() and gmmktime() rather than the regular versions??

anyway, minor issue. Thanks maN! great help here!

tea

dalecosp

Originally posted by Tea_J
i dont see how the SECONDS PASSED since epoch to my SPECIFIED EXACT DATE (April 1, 2005) would be timezone dependent.. basically, SECONDS are UNIVERSAL.

Umm, well, I can see where you might have some trouble with this.

But keep this in mind: The Epoch happened 24 times. 😉

It's where the machine is starting counting from that is the issue....

Tea_J

alrite.. get ready to be bugged further..

Umm, well, I can see where you might have some trouble with this.

But keep this in mind: The Epoch happened 24 times.

It's where the machine is starting counting from that is the issue...

well that's just it dude.. that's what i dont get.. lolz

you see.. here's an example..

my EXACT DATE is April 3, 2005.. let's say 1:00PM (or 13:00)

there are 60 seconds in a minute and 60 minutes in an hour.. 24 hours in a day..

Now lets say epoch started April 1, 2005..

Now. i want to know how many seconds have passed since April 1 to April 3

So that's
24 hours x 3 + 13 = 85hrs
85 x 60 = 5100 minutes
5100 x 60 = 306000

I dont see how different timezones can affect the result of the above equation..

No matter how i look at it... if i specify the exact RANGE of what i want to calculate from START to END, THERE ARE NO VARIABLES in between.. it's like point A to point B and that's it..

Another way at looking at it..
In ONE hour (360 seconds) starting from 1:00PM ... I want to know how many seconds passed since start time to 1:45PM

Thats 2700 seconds..

Now.. I dont see how the result should be different if this was calculated in different places in the world

what the hell am I missing here??

😕

tea

dalecosp

[534] Mon 02.May.2005 16:08:58 
[kadmin@ezekiel][~/scripts]
# cat time && php time
<?php


function line() {
   echo "\n";
}

echo "time stamp: ".date("U");
line();
echo "Time zone setting: ".date("T");
line();
echo "Difference to Greenwich: ".date("O");
line();

$check=strtotime("00:00:01 January 2, 1970");
echo "check is $check";
line();
echo date("Y-m-d", $check);
line();

?>

time stamp: 1115068144
Time zone setting: CDT
Difference to Greenwich: -0500
check is 108001
1970-01-02

[571] Mon 02.May.2005 16:08:10
[kadmin@archangel][~/scripts]                                                                                            #php time
time stamp: 1115068121
Time zone setting: BST
Difference to Greenwich: +0100
check is 82801
1970-01-02

This might illustrate. The two machines executed the script called "time" about the same time (they say they're 42 seconds apart; seems like maybe I need to track down an NTP problem, as "archangel" is supposed to sync to "ezekiel", but seems to be reporting as stratum 16 instead of strat 3...I played with the firewall yesterday and may have messed things up a bit ... :eek: )

Anyway, although both give the same system time, archangel is set to BST (British Standard Time), one hour on the other (east) side of Greenwich. Ezekiel, here in Missouri, is set to US Central Time. Note that the machine results for the date known as "1 minute past midnight on January 2, 1970" are 7 hours apart.....

Tea_J

hmm. thanks for the illustration mate.. though i dont completely understand yet, i understand enough about the date stuff to be able to sleep well at night.. 🙂

but.. im still absolutely confused as to calculating the SECONDS PASSED BETWEEN 2 SPECIFIDE DATE AND TIME..

Lemme ask you how many seconds has passed...

since January 1, 2005, 12MN (pretending that's epoch),

to FEB 1, 2005 12MN (pretending this is my target time)...

wherever we both are in the world, I think we will both have the same answer...

time() should be the same scenario as the above..

should a server be hours ahead or late, it shouldnt matter..

Thanks for your patience with me. 😃

regards

tea

Weedpacket

Originally posted by Tea_J
the SECONDS PASSED BETWEEN 2 SPECIFIDE DATE AND TIME..

In which two timezones? Without the timezone, your specification is incomplete and therefore ambiguous.

2005-01-01 00:00:00 PST is not the same thing as 2005-01-01 00:00:00 UTC. If one of the timestamps is generated in one timezone, and the other timestamp is generated in the other timezone, the difference in timezones will need to be taken into account.

should a server be hours ahead or late, it shouldnt matter..

It will if you don't take the fact that they're in different timezones into account. The difference between 2004-12-11 12:00:00 PST and 2004-12-11 13:00:00 UTC is not one hour, it's seven.