|
|
Posted by Rik on 01/16/07 20:12
Tim Roberts wrote:
> Christoph Burschka <christoph.burschka@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
Navigation:
[Reply to this message]
|