Posted by Gordon Burditt on 11/29/05 19:54

>I have a client's website running on Linux at www.dsvr.co.uk, a well
>respected hosting company, and PHP's mktime() as on many Linux versions
>still can't handle dates prior to 1970. This is madness. Can anyone explain
>why the problem with mktime()'s dependence on glibc STILL hasn't been
>addressed as of PHP 5? I can't believe the PHP developers continute to keep
>their head in the sand with regard to mktime() and it's problems dealing
>with dates prior to 1970. It's no good blaming glibc. If glibc is
>problematic dependence on it should have been dropped long ago. Perl's
>Date::Calc doesn't suffer from these problems.

I wish PHP had a date representation OTHER than a unix timestamp
for date calculations. Pretty much all of the date/time functions
are limited by this. Of course, changing this is going to be a
problem because there are undoubtedly lots of scripts that store
that representation in files or databases. A 32-bit Unix timestamp
is limited to 1970 - 2038 for the "positive" range, and depending
on whether it's considered signed or unsigned, to 1901-1969 or
2038-2106 for the part with the high bit set.

MySQL uses a text representation of the form: 2005-11-28 15:01:38.
It has potential Y10K problems, but most of the date/time functions
other than the couple which input or output a unix timestamp are
not limited to a couple of centuries. Functions like adding x
seconds to a timestamp are, however, much more complicated and
there's a lot of functionality I'd like to see that isn't implemented.

I prefer to use MySQL's date math where the date involved isn't
tied to something like a file stamp. For example, a UNIX timestamp
is hopeless for birth dates or expected retirement dates.

Gordon L. Burditt

[Back to original message]