cookie expire time and time zones

D

David Graham

Hi
I have asked this question in alt.php as the time() function as used in
setcookie belongs to php - or does it belong equally in the javascript
camp - bit confused about that. Anyway, can anyone here put me straight on
the following:

I had a look at the time() function came across this:

"To clarify, it seems this function returns the time of the computer's clock
and does not do any timezone adjustments to return GMT, so you are given the
local time. The description says that it's supposed to return the number of
seconds from 1970 12am GMT, when the seconds are actually counted from 12am
in the computer's local time.

Hope it saves some confusion. "

This seems to be saying that the time() function retreaves the date in
seconds from 1970 12a.m from the users pc clock. This is great for me, it
means I don't need to worry about time zones. My cookie will expire in
60seconds (time() + 60) regardless of where the user lives. Have I
interpreted things correctly?
thanks
David
 
M

Michael Winter

David Graham wrote on 20 Nov 2003:
Hi
I have asked this question in alt.php as the time() function as
used in setcookie belongs to php - or does it belong equally in
the javascript camp - bit confused about that. Anyway, can
anyone here put me straight on the following:

I had a look at the time() function came across this:

"To clarify, it seems this function returns the time of the
computer's clock and does not do any timezone adjustments to
return GMT, so you are given the local time. The description
says that it's supposed to return the number of seconds from
1970 12am GMT, when the seconds are actually counted from 12am
in the computer's local time.

Hope it saves some confusion. "

This seems to be saying that the time() function retreaves the
date in seconds from 1970 12a.m from the users pc clock. This is
great for me, it means I don't need to worry about time zones.
My cookie will expire in 60seconds (time() + 60) regardless of
where the user lives. Have I interpreted things correctly?

It seems to me that it's saying it returns the client's local time,
and not GMT/UTC, so you *will* have to worry about time-zones: cookie
expiry dates *must* be in GMT/UTC, not local time. However, you can
use the PHP function, gmdate():

// Returns the current date and time, in GMT, in the (cookie) format:
// Wdy, DD-Mon-YY HH:MM:SS GMT
//
gmdate( "D, d-M-Y H:i:s \G\M\T", time());

In JavaScript, you'd just use the Date.toUTCString() method.

Hope that helps,

Mike
 
D

David Graham

Michael Winter said:
David Graham wrote on 20 Nov 2003:


It seems to me that it's saying it returns the client's local time,
and not GMT/UTC, so you *will* have to worry about time-zones: cookie
expiry dates *must* be in GMT/UTC, not local time. However, you can
use the PHP function, gmdate():

// Returns the current date and time, in GMT, in the (cookie) format:
// Wdy, DD-Mon-YY HH:MM:SS GMT
//
gmdate( "D, d-M-Y H:i:s \G\M\T", time());

In JavaScript, you'd just use the Date.toUTCString() method.

Hope that helps,

Mike

Hi
Why is nothing ever simple.
I have been to the php manual to look up details on gmdate() function. I
note something about the function being broken in MS Windows OS - is this a
serious problem, if so I will stay clear of this function. I have pasted the
line below from the maual

header("Expires: ".gmdate("D, d M Y H:i:s", time() + 3600)." GMT");

I think this is saying - get the corrected date and time - i.e. whatever the
local time may be, correct it to GMT. Then the second argument is get the
lapsed seconds since 1970 Jan 1st and add an hours worth of seconds to this
(time that cookie exists for). Then I get confused as to how this helps me
in setcookie() to set a cookie expire time. Obviously, when I use this stuff
for real I will strip away the header() bit and the concatonated strings at
the start and finish. But the actual detail of how that second argument
combines with the GMT to set an expire time is something I'm not getting at
the moment. Need a bit more help please to understand this.
David
 
M

Michael Winter

David Graham wrote on 20 Nov 2003:
Hi
Why is nothing ever simple.
I have been to the php manual to look up details on gmdate()
function. I note something about the function being broken in MS
Windows OS - is this a serious problem, if so I will stay clear
of this function. I have pasted the line below from the maual

header("Expires: ".gmdate("D, d M Y H:i:s", time() + 3600)."
GMT");

I think this is saying - get the corrected date and time - i.e.
whatever the local time may be, correct it to GMT. Then the
second argument is get the lapsed seconds since 1970 Jan 1st and
add an hours worth of seconds to this (time that cookie exists
for). Then I get confused as to how this helps me in setcookie()
to set a cookie expire time. Obviously, when I use this stuff
for real I will strip away the header() bit and the concatonated
strings at the start and finish. But the actual detail of how
that second argument combines with the GMT to set an expire time
is something I'm not getting at the moment. Need a bit more help
please to understand this. David

I just looked at the comments on those functions in the PHP online
documentation. It seems that you missed one comment, and
misinterpreted (sort of) your most recent concern:

The poster that suggested time() returns values relative to local
time was apparently mistaken. The comment immediately above it claims
that time() is correct, and the mistaken poster was probably using
date() (which adjusts a timestamp to local time) to display the
return value. I would have suggested that you try it for yourself,
but I see that we're both in the UK, so date() and gmdate() would
return the same time for us. I wrote a small test page and tried
changing my time-zone settings, but it was determined to return
everything in GMT, so I was unable to verify anything.

The problem with a Windows server and gmdate() is when you pass
negative timestamps. This would only be a problem if you intend to
parse dates before 01-Jan-1970 00:00:00 GMT (UNIX Epoch). There is no
way of getting around this (date() too is limited to dates after the
UNIX Epoch).

About the date formatting, use my string ("D, d-M-Y H:i:s \G\M\T") as
it is guaranteed to be the correct format. The 'T' format specifier
could return any string that infers GMT. During my test with gmdate()
and date(), 'T' returned 'GMT Standard Time' - it depends upon the
operating system.

In a nutshell, you needn't really worry about the concerns you've
raised, unless you want to use a date before the UNIX Epoch, and then
there's nothing you can do about it directly anyway. The safest way
would be to use a host that runs Unix or Linux: they're free from
that particular error.

Mike
 
D

David Graham

The poster that suggested time() returns values relative to local
time was apparently mistaken. The comment immediately above it claims
that time() is correct, and the mistaken poster was probably using
date() (which adjusts a timestamp to local time) to display the
return value. I would have suggested that you try it for yourself,
but I see that we're both in the UK, so date() and gmdate() would
return the same time for us. I wrote a small test page and tried
changing my time-zone settings, but it was determined to return
everything in GMT, so I was unable to verify anything.
Thanks for all your help Michael.
If the time() function does not return values relative to local time, then
that is probably why I see coders mostly setting their cookies like this

setcookie("cookiename", "cookievalue", time() + 3600)

i.e. they make no effort to allow for timezones. But that can't be correct -
php has not produced the function gmdate( "D, d-M-Y H:i:s \G\M\T", time());
for no good reason. Any ideas why it is rare to see gmdate() being used?
David
 
M

Michael Winter

David Graham wrote on 21 Nov 2003:

But that can't be correct - php has not produced the function
gmdate( "D, d-M-Y H:i:s \G\M\T", time()); for no good reason. Any
ideas why it is rare to see gmdate() being used?

I couldn't honestly say. The only reason that I might not use
gmdate() is because of the pre-UNIX Epoch problems I mentioned*, but
date() suffers from those problems, too. However, I'm not likely to
write anything that would need to parse dates prior to 1970. In fact,
the only practical things I can see that would need to is a calendar
of some sort, or when parsing someone's birthday in a membership list
(if it's stored as a timestamp, not a string).

If it's going to be used purely for cookies, then I see no reason at
all not to use it. You aren't going to set a cookie to expire prior
to 1970 (setting it to last week, or - even simpler - timestamp 0,
would do that). In fact, you're violating the RFC relating to cookies
by not using it as they must use GMT time.


Mike

P.S. Sorry for repeating myself.

* However, most PHP hosts I know of use UNIX/Linux hosts, which don't
have any problems with the date libraries.
 
D

Dr John Stockton

JRS: In article <[email protected]>,
seen in David Graham
If the time() function does not return values relative to local time, then
that is probably why I see coders mostly setting their cookies like this

setcookie("cookiename", "cookievalue", time() + 3600)

i.e. they make no effort to allow for timezones. But that can't be correct -
php has not produced the function gmdate( "D, d-M-Y H:i:s \G\M\T", time());
for no good reason. Any ideas why it is rare to see gmdate() being used?

Since this is, AFAICS, a PHP discussion, it should be moved to a PHP
newsgroup or to E-mail.
 

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments. After that, you can post your question and our members will help you out.

Ask a Question

Members online

No members online now.

Forum statistics

Threads
473,734
Messages
2,569,441
Members
44,832
Latest member
GlennSmall

Latest Threads

Top