mktime fails for pre 1970 on Fedora 3

[zaphod]

Fedora 3
Apache 2
PHP 5.0

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.

zaphod

[Tim Roberts]

zaphod <no**@none.com> wrote:

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.

It's not glibc. It is much more deeply embedded in the depths of the
operating system. Just try to work with a date past February, 2038.
--
- Tim Roberts, ti**@probo.com
Providenza & Boekelheide, Inc.

[Gordon Burditt]

>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

[Andy Hassall]

On Tue, 29 Nov 2005 17:54:37 -0000, go***********@burditt.org (Gordon Burditt)
wrote:

I wish PHP had a date representation OTHER than a unix timestamp
for date calculations.

There's always http://pear.php.net/package/Date

PHP 5.1.0 had a "new native date class" for about 5 minutes until they
withdrew it in 5.1.1 - not sure of the details of that.
--
Andy Hassall :: an**@andyh.co.uk :: http://www.andyh.co.uk
http://www.andyhsoftware.co.uk/space :: disk and FTP usage analysis tool

[gunzip]

Tim Roberts wrote:

It's not glibc. It is much more deeply embedded in the depths of the
operating system. Just try to work with a date past February, 2038.

I'm not referring to the 32/64 bit issue. On some UNIX platforms, such as
FreeBSD, mktime handles pre-1970 dates with a workable negative value. On
many Linux distros all you get for anything before 1 Jan 1970 is -1. If
Perl's Date::Calc can handle all this why can't PHP?

zaphod

[Gordon Burditt]

>> It's not glibc. It is much more deeply embedded in the depths of the

operating system. Just try to work with a date past February, 2038.
I'm not referring to the 32/64 bit issue.

This isn't the 32/64 bit issue. This is the 31/32 bit issue.
On some UNIX platforms, such as
FreeBSD, mktime handles pre-1970 dates with a workable negative value. On
many Linux distros all you get for anything before 1 Jan 1970 is -1. If
Perl's Date::Calc can handle all this why can't PHP?

An OS with a 32-bit time_t has a choice. With the "negative" values
of a 32-bit integer, it can represent 1901-1969 or 2038-2106: pick
one. I take it Linux chose to handle 2038-2106, and you don't like
that choice.

I think POSIX says it's supposed to be unsigned, so arguably
Linux is right and the BSDs are wrong as far as standards compliance.
Gordon L. Burditt