187254 - Cookie expiration date is limited to 01/18/2038 10:14:07 PM

Status: RESOLVED FIXED

(Core :: Networking: Cookies, defect)

Description

[Jonadab the Unsightly One (Nathan Eady)]

User-Agent:       Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.3a) Gecko/20021212
Build Identifier: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.3a) Gecko/20021212

I'm amazed this hasn't been filed, but all the 2038 bugs I can find are Windows
only and don't seem to describe the same problem; although they do have to do
with cookies, they also involve Javascript and have different (albeit worse)
results.  (See bug 27070, for example.)  I know this won't be a priority in 
2003, but it needs to be filed sooner or later, so while I'm thinking about it,
here it is.

Reproducible: Always

Steps to Reproduce:
1.  If you have set a max limit on cookie lifetimes in your prefs,
    turn it off for a moment.
2.  Visit http://cgi.galion.lib.oh.us/scripts/cookie2038.pl
3.  Tools->Cookie Manager->Manage Stored Cookies
4.  Scroll down to cgi.galion.lib.oh.us
5.  Look at the Expires:  time.

Actual Results:  
01/18/2038 10:14:07 PM

Expected Results:  
01/01/3000 00:00:00 GMT


The cookie header being sent is as follows:
Set-Cookie: cookiedemonstration=$now; expires=Wed, 01 Jan 3000 00:00:00 GMT

$now comes straight from localtime().  I can attach the script if desired,
but that seems unnecessary to me, so I won't unless requested.  This is not
a very big deal yet, but it will eventually matter.  Setting severity to 
minor since we have years to fix this.

If you turned off your usual expiration-time limit for testing this, don't
forget to put it back.

Comment 1

[tenthumbs]

Actually,
  2147483647: Tue, 19 Jan 2038 03:14:07 UTC
That's when the 32-bit integers overflow. It's a fundamental issue with all
Unix-like systems. It's well known and there will be a fix eventually. Don't
worry about it. For Windows overflow occurs 10 years later.

Since this is not a mozilla problem, marking this invalid, although invalid
sounds so nasty.

Comment 2

[Tim]

This is technically the fault of the cookies module, since Mozilla's time type
is 64-bit (see PRTime). The 32-bit limit is hitting here because
http://lxr.mozilla.org/seamonkey/source/extensions/cookie/nsCookies.cpp uses
time_t instead of PRTime.  Just thought I'd mention it, even if only for posterity.

Comment 3

[tenthumbs]

So I'm a doofus. Let's reopen this. Is it really worth worrying about 
what will happen long after mozilla is dust?

Comment 4

[[e-mail]]

Yes, because it's bad programming practice to be casting 64-bit int's into
smaller types, when we don't need to.

We have a lovely class, nsTime (and nsInt64) in xpcom/ds, which define
overloaded operators to make use of 64-bit beasts pretty easy. (see bug 188845)

Marking a blocker for cookie rewrite (bug 187304), I'll fix this one up.

Comment 5

[[e-mail]]

-> me

Comment 6

[[e-mail]]

marking reso/fixed per bug 195908.