Blog2014 ≫ Y2038 bug spotted in the wild

I'm old enough to remember when people panicked about the y2k bug, how when the clocks ticked over from 1999 to 2000 all the computers were going to fall over. There's a similar fear around the year 2038... from wikipedia:

The problem affects all software and systems that both store system time as a signed 32-bit integer, and interpret this number as the number of seconds since 00:00:00 UTC on Thursday, 1 January 1970.[1] The furthest time that can be represented this way is 03:14:07 UTC on Tuesday, 19 January 2038 (2147483647 seconds after January 1st, 1970).

I just spotted this bug in the wild. Someone had been setting a cookie with a long expiry date, so this site would try to identify you when you came back, any time up to 25 years in the future. Web pages do this by setting a "header", a bit of info that is sent back to your browser before the content, that your web browser knows how to deal with. The problem is that when "25 years in advance" is expressed as the kind of number we have to send to the browser, it's just too big to fit into a 32-bit integer, so it all goes bang. Try out the php on your 32 bit system:

[code] $ php -r 'echo strtotime( "+23 years" );' 2129038221 # that date, expressed as a number $ php -r 'echo strtotime( "+25 years" );'

hey where did that number go?

[/code]

I think we'll set the cookie for two years ahead, and put this problem off for another 22 years..

⬅️ :: ➡️

Paul Clarke's weblog - I live in A small town. Wed to Clare + father to two, I'm a full stack web engineer, and I do mostly js / nodejs, some ruby, other languages ect ect. I like pubs, running, eating, home-automation and other diy stuff, history, genealogy, TV, squirrels, pirates, lego, + time travel.