Question

I have been helping someone debug some code where the error message was “Day too big”. I know that this springs from localtime and the Y2038 bug (most google results appear to be people dealing with cookies expiring well into the future).

We appear to have ‘fixed’ the problem by using time to get the current date. However, given that none of our original dates should have hit the 2038 issue I’m sceptical that we’ve actually fixed the problem …

Are there other instances that anyone knows of where one would hit “day too big”?

OS is Solaris.

Sample code – the actual code is quite large and the person I’m working with hasn’t actually isolated the offending part (which is why I’m worried the ‘fix’ is not actually a fix). If I can put together something concise which reproduces the issue I will post!

UPDATE

I isolated the bit of code, put some print statements around everything and have solved the problem …

The offending line of code was:

$temp = str2time(localtime());

This was often (but not always) setting $temp as undef. It turns out that even when $temp was being set it wasn’t being set with the expected value.

The gotcha is that localtime() returns an array in most contexts … and that’s what’s messing up the call to str2time.

By changing this to:

$ltime = localtime;
$temp = str2time($ltime);

the problem goes away.

Of course, better yet, just use:

$temp = time;

Answer 1

There’s a “Day too big” message from the Time::Local package. The source code is here if you want to investigate further.

The Carp::Always module might be helpful here. Run the offending code with

perl -MCarp::Always script.pl arg1 arg2 ...

and wherever you got a warning before, you will now get a full stack trace.