strtotime and a very mysterious date

Namely the thirteenth of December 1901, 12:45:52, Pacific Time.

All dates later than this passed in format "yyyy-mm-dd hh:mm:ss" to the
strtotime function return the correct unix timestamp value (as can be
verified by passing it back to date()).

If a date earlier than 1901-12-13 12:45:52 is used, it returns an error.
I tried this for a while to find the exact cut-off point, and this is it.

Any reason - possibly a limitation of the integer value that is used? I
didn't find this documented anywhere...

--
Christoph Burschka

Christoph Burschka schrieb:

Quote:

Namely the thirteenth of December 1901, 12:45:52, Pacific Time.
>
All dates later than this passed in format "yyyy-mm-dd hh:mm:ss" to the
strtotime function return the correct unix timestamp value (as can be
verified by passing it back to date()).
>
If a date earlier than 1901-12-13 12:45:52 is used, it returns an error.
I tried this for a while to find the exact cut-off point, and this is it.
>
Any reason - possibly a limitation of the integer value that is used? I
didn't find this documented anywhere...
>
--
Christoph Burschka

Whoops, I should have checked more closely. In fact this *is* documented
as the minimal value of most dates due to the length of the 32-bit integer.

I never considered that these "Y2K" problems work backwards, too...

--
Christoph Burschka

Christoph Burschka <christoph.burschka@rwth-aachen.dewrote:

Quote:

>Christoph Burschka schrieb:

Quote:

>Namely the thirteenth of December 1901, 12:45:52, Pacific Time.
>>
>All dates later than this passed in format "yyyy-mm-dd hh:mm:ss" to the
>strtotime function return the correct unix timestamp value (as can be
>verified by passing it back to date()).
>>
>If a date earlier than 1901-12-13 12:45:52 is used, it returns an error.
>I tried this for a while to find the exact cut-off point, and this is it.
>>
>Any reason - possibly a limitation of the integer value that is used? I
>didn't find this documented anywhere...

>
>Whoops, I should have checked more closely. In fact this *is* documented
>as the minimal value of most dates due to the length of the 32-bit integer.
>
>I never considered that these "Y2K" problems work backwards, too...

The upper end of this range is coming up as well, in the middle of
February, 2038.
--
Tim Roberts, timr@probo.com
Providenza & Boekelheide, Inc.

Tim Roberts wrote:

Quote:

Christoph Burschka <christoph.burschka@rwth-aachen.dewrote:
>

Quote:

>Christoph Burschka schrieb:

Quote:

>>Namely the thirteenth of December 1901, 12:45:52, Pacific Time.
>>>
>>All dates later than this passed in format "yyyy-mm-dd hh:mm:ss" to
>>the strtotime function return the correct unix timestamp value (as
>>can be verified by passing it back to date()).
>>>
>>If a date earlier than 1901-12-13 12:45:52 is used, it returns an
>>error. I tried this for a while to find the exact cut-off point,
>>and this is it.
>>>
>>Any reason - possibly a limitation of the integer value that is
>>used? I didn't find this documented anywhere...

>>
>Whoops, I should have checked more closely. In fact this *is*
>documented as the minimal value of most dates due to the length of
>the 32-bit integer.
>>
>I never considered that these "Y2K" problems work backwards, too...

>
The upper end of this range is coming up as well, in the middle of
February, 2038.

And that's sooner a problem then you think. What if you want to calculate
new mortgages? That's a field where 2038 is very, very close...
--
Rik Wasmus

strtotime and a very mysterious date

re: strtotime and a very mysterious date

re: strtotime and a very mysterious date

re: strtotime and a very mysterious date

Similar PHP bytes

/bytes/development

/bytes/it

/bytes/about