Be Careful with Dates

The year 2000 came and went, and the world went on.  There were no horrific date rollover bugs, despite all the press.  However, that doesn't mean that date rollover issues do not exist.

I just debugged a date rollover issue.  It manifested as follows:

Our application worked fine in our local environment (of course), but when we deployed to a customer's server, the cookies didn't work.  We took a look at the HTTP Headers using Chrome, and everything seemed fine.  But still they didn't work.

However, when I took a close look at the headers in our test environment and the server environment, the issue jumped right out at me.

Here was the header from our local environment:

Set-Cookie:prop1=value1;Path=/ourapp;Expires=Mon, 10-Jun-2080 00:13:42 GMT

And on the customer's server:

et-Cookie:prop1=value1; Expires=Sun, 09-Jun-80 23:59:24 GMT; Path=/ourapp

Do you see it?  It is rather obvious.

It is a date roll-over issue.

The problem was caused when we set the cookie expiration date to Integer.MAX_VALUE.  This resulted in a date some time in 2080.  In our local environment, Jetty handles this properly and uses a long date format for the year.

However, the production server uses IBM WebSphere, and it takes a short cut.  It simply renders 2080 as 80.

So the browser sees the date and discards it as expired.  Apparently it doesn't use the 'context clue' of Sun to determine which century the date is in...

By setting a realistic expiration date for the cookie, it works just fine.

We were distracted for a bit by IBM WebSphere adding: Cache-Control:no-cache="set-cookie, set-cookie2"  However in the end that seems to be unrelated.

Hope this can help someone else.