hi

I did not know that timesstamp could be negative, and display dates BEFORE 1970.

Unix timestamp in PHP uses 32 bits to store data.
This means that timestamp value can be:
MAX: 2147483647 = 2038-01-19 03:14:07 +0000
MIN:-2147483648 = 1901-12-13 20:45:52 +0000
( see my script below )

So, timestamp, at present, is useful 13 Dec 1901 - 19 Jan 2038.
When writing scripts for historical dates before 1902,
I think, unix timestamp can not be used.

When PHP in future will be adjusted to 64 bits computers
this probably means any historical and future dates
can be used with timestamp.

Or maybe there will be a new system recplacing Unix timestamp?

==================
Output of my test script:

2038-01-19 03:14:07 +0000 -2147483649
1901-12-13 20:45:52 +0000 -2147483648
1901-12-13 20:45:53 +0000 -2147483647

1970-01-01 00:00:00 +0000 0

2038-01-19 03:14:06 +0000 2147483646
2038-01-19 03:14:07 +0000 2147483647
1901-12-13 20:45:52 +0000 2147483648

<?php

$stamp = -2147483649; echo gmdate( "Y-m-d H:i:s O", $stamp ).' '.$stamp.'<br>';
$stamp = -2147483648; echo gmdate( "Y-m-d H:i:s O", $stamp ).' '.$stamp.'<br>';
$stamp = -2147483647; echo gmdate( "Y-m-d H:i:s O", $stamp ).' '.$stamp.'<br>';
echo '<br>';
$stamp = 0; echo gmdate( "Y-m-d H:i:s O", $stamp ).' '.$stamp.'<br>';
echo '<br>';
$stamp = 2147483646; echo gmdate( "Y-m-d H:i:s O", $stamp ).' '.$stamp.'<br>';
$stamp = 2147483647; echo gmdate( "Y-m-d H:i:s O", $stamp ).' '.$stamp.'<br>';
$stamp = 2147483648; echo gmdate( "Y-m-d H:i:s O", $stamp ).' '.$stamp.'<br>';

?>

    Unix timestamp works... but it's from the unix epoch which kind of limits it...

    But here's my theory: We have AD/BC times. AD being now (starting at 1 and continuing to 2006). BC starts at -1 and continues to -infinity.... So a Unix-timestamp should (in my eyes) work just like that: 0 is Jan 1, 1970 and negative is prior to 1970, positive is after 1970....

    It's interesting that you bring this up. When we do switch to 64-bit integers, it'd be nice to have the ability to go further into the future; however, until 2020 I don't think we'll need to go past 2038 😉

      bpat1434 wrote:

      It's interesting that you bring this up. When we do switch to 64-bit integers, it'd be nice to have the ability to go further into the future; however, until 2020 I don't think we'll need to go past 2038 😉

      I agree that is very limited needs to go beyond 2038 in applications.
      But at the other end, backwards,
      there could be scripts of historical nature that goes a long way back in timeline.
      Such scripts can of course easily use some custom way
      to set dates and times.

      And this is what Genealogy Scripts are doing.
      There are many such, that can display day of birth and day of death
      of ancestors in passed centuries.

      🙂

        bpat1434 wrote:

        however, until 2020 I don't think we'll need to go past 2038 😉

        I dunno, I'm thinking 2008/2009 the s**t might hit the fan. At that point banks will care--30 yr. mortgages starting to fall on/after 2038 end date. Just a thought...

          The problem isn't the operating system (computers will be upgraded long before then - how many 40-year-old computers are there still operating? Not even the Space Shuttle's computers are that old.) It's all the databases (and applications) that will need upgrading. (If I have any reason to anticipate operation over long periods, I use Julian Days anyway: that reaches six thousand years into the past without having to go negative).

          However, I feel obligated to point out that having negative Unix timestamps to represent dates prior to 1970 has always been a part of Unix; it was Windows that was stupid enough to both (a) use a Unix-like signed integer to represent timestamps while (b) ignoring the sign bit - instantly halving its effective range. The PHP manual actually mentions this on its [man]date[/man] page.

          So the problems are already starting: http://thedailywtf.com/forums/thread/78254.aspx

            Write a Reply...