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:
> 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 [at] rwth-aachen.de> wrote:

>Christoph Burschka schrieb:
>> 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 [at] probo.com
Providenza & Boekelheide, Inc.

Tim Roberts wrote:
> Christoph Burschka <christoph.burschka [at] rwth-aachen.de> wrote:
>
>> Christoph Burschka schrieb:
>>> 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

Christoph Burschka schrieb:
> 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 [at] rwth-aachen.de> wrote:

>Christoph Burschka schrieb:
>> 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 [at] probo.com
Providenza & Boekelheide, Inc.

Tim Roberts wrote:
> Christoph Burschka <christoph.burschka [at] rwth-aachen.de> wrote:
>
>> Christoph Burschka schrieb:
>>> 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