Re: Problem creating a date before 1970 on Fedora

On Mon, 13 Sep 2004 12:39:26 -0500, Greg Donald <destiney@gmail.com> wrote: > > > On Mon, 13 Sep 2004 19:03:09 +0200, Wouter van Vliet > <wouter.van.vliet@gmail.com> wrote: > > Howdy, > > > > I would assume this to be a common problem, but as I wrote to this > > list myself a couple of days ago I was only aware of it's existence on > > windows systems. Here's some sample code > > > > 1 <?php > > 2 $date = strtotime('12 feb 1950'); > > 3 print $date.': '.date('r', $date)."\n"; > > 4 $date = mktime(0,0,0,2,12,1950); > > 5 print $date.': '.date('r', $date)."\n"; > > 6 ?> > > > > And this is it's output: > > > > -1: Thu, 1 Jan 1970 00:59:59 +0100 > > -3662: Wed, 31 Dec 1969 23:58:58 +0100 > > > > My search on google didn't help me out, the docs say that it should > > work and I can remember me having used such code and got it working. > > Please fella's, what am I missing? > > The bottom of the strtotime() manual page where it says: > > Note: The valid range of a timestamp is typically from Fri, 13 Dec > 1901 20:45:54 GMT to Tue, 19 Jan 2038 03:14:07 GMT. (These are the > dates that correspond to the minimum and maximum values for a 32-bit > signed integer.) Additionally, not all platforms support negative > timestamps, therefore your date range may be limited to no earlier > than the Unix epoch. This means that e.g. dates prior to Jan 1, 1970 > will not work on Windows, some Linux distributions, and a few other > operating systems. > > A couple years ago when upgrading some web servers we found RedHat 7 > had this issue, strtotime() basically didn't work and always returned > -1 on 'negative' unix timestamps. I have never used Fedora but it's > probably the same issue all over again. I know this isn't the answer > you were hoping for, but I wanted to share my experience. > so, basically my problem is confirmed to be existent - such a relieve ;) It's just that ppl I work for do want to be able to be born before 1970, cuz some are. Mashed patatoes :@ - is there really no way to deal with this? Might somebody have created a nice rpm of the kernel with t_*smth* set to 64 or 32 bits signed? I have full control over the server, so if i'd need to make any changes, that is possible.