32bit vs 64bit - 32bit can't handle 2100 in strtotime?
 

Hi,

I would like to note that I am aware of that 32 bit systems will not
work after 2038. But does that mean that they can not do simple date
conversion?

<?php
$now = date('Y-m-d H:i:s', time());
$future = "2100-01-01 01:01:01";
$now_stt = strtotime($now);
$future_stt = strtotime($future);
var_dump($now);
var_dump($now_stt);
var_dump($future);
var_dump($future_stt);
?>

32-bit system

string(19) "2011-06-27 09:17:10" int(1309159030) string(19)
"2100-01-01 01:01:01" bool(false)


64-bit system

string(19) "2011-06-27 09:18:28" int(1309159108) string(19)
"2100-01-01 01:01:01" int(4102444861)




--
Best regards,
Michal

http://eventhorizon.pl/
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

32bit vs 64bit - 32bit can't handle 2100 in strtotime?
 

2011/6/27 Michał Piotrowski <mkkp4x4@gmail.com>:
> Hi,
>
> I would like to note that I am aware of that 32 bit systems will not
> work after 2038. But does that mean that they can not do simple date
> conversion?

Where is the difference ... overflowing the 32bit integer due to the
current date being past 2038 or by setting it by hand?
Just move on to the current century and install a 64bit os ;)
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

32bit vs 64bit - 32bit can't handle 2100 in strtotime?
 

2011/6/27 drago01 <drago01@gmail.com>:
> 2011/6/27 Michał Piotrowski <mkkp4x4@gmail.com>:
>> Hi,
>>
>> I would like to note that I am aware of that 32 bit systems will not
>> work after 2038. But does that mean that they can not do simple date
>> conversion?
>
> Where is the difference ... overflowing the 32bit integer due to the
> current date being past 2038 or by setting it by hand?
> Just move on to the current century and install a 64bit os ;)

I can't - it's project manager's test machine and it's 32-bit Intel T2300 :)

If it were not 32-bit machine we certainly would not notice the
occurrence of the problem :)

> --
> devel mailing list
> devel@lists.fedoraproject.org
> https://admin.fedoraproject.org/mailman/listinfo/devel



--
Best regards,
Michal

http://eventhorizon.pl/
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

32bit vs 64bit - 32bit can't handle 2100 in strtotime?
 

Michał Piotrowski <mkkp4x4@gmail.com> writes:

> I would like to note that I am aware of that 32 bit systems will not
> work after 2038. But does that mean that they can not do simple date
> conversion?

If they use the system time_t, then no.

Andreas.

--
Andreas Schwab, schwab@redhat.com
GPG Key fingerprint = D4E8 DBE3 3813 BB5D FA84 5EC7 45C6 250E 6F00 984E
"And now for something completely different."
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

32bit vs 64bit - 32bit can't handle 2100 in strtotime?
 

> I would like to note that I am aware of that 32 bit systems will not
> work after 2038. But does that mean that they can not do simple date
> conversion?

Yes, if "simple date conversion" uses a 32-bit time_t and does not
check-and-correct for 32-bit wrap-around.

On a system which uses a 32-bit time_t, then some user code has problems
with the calculations for a 30-year mortgage with an origination date
of 2008 or later. One common workaround is to use a temporary origin
of something like 1980-01-01T00:00 instead of 1969-01-01T00:00.
Using 1980 allows the same code to work for any _existing_ 30-year
mortgage as well as new ones.

--
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

32bit vs 64bit - 32bit can't handle 2100 in strtotime?
 

Once upon a time, Michał Piotrowski <mkkp4x4@gmail.com> said:
> I would like to note that I am aware of that 32 bit systems will not
> work after 2038. But does that mean that they can not do simple date
> conversion?

Not if that "simple" date conversion uses the system time_t functions
(which most of the common functions do). If you need to handle dates
outside the range of 1970-2038, you'll need to use alternate functions
that can handle the expected date range (and I don't know if such exist
in PHP; you may have to code them yourself).

Portable code should not assume system date routines can handle dates
outside 1970-2038; you shouldn't depend on 64 bit systems having larger
time_t (I don't think they all do).
--
Chris Adams <cmadams@hiwaay.net>
Systems and Network Administrator - HiWAAY Internet Services
I don't speak for anybody but myself - that's enough trouble.
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

32bit vs 64bit - 32bit can't handle 2100 in strtotime?
 

2011/6/27 John Reiser <jreiser@bitwagon.com>:
>> I would like to note that I am aware of that 32 bit systems will not
>> work after 2038. But does that mean that they can not do simple date
>> conversion?
>
> Yes, if "simple date conversion" uses a 32-bit time_t and does not
> check-and-correct for 32-bit wrap-around.
>
> On a system which uses a 32-bit time_t, then some user code has problems
> with the calculations for a 30-year mortgage with an origination date
> of 2008 or later. Â*One common workaround is to use a temporary origin
> of something like 1980-01-01T00:00 instead of 1969-01-01T00:00.
> Using 1980 allows the same code to work for any _existing_ 30-year
> mortgage as well as new ones.
>

Ok, thanks for your answers. I removed all uses of 2100 year from my
data, so now code runs fine on 32 bit machine. I am afraid that this
problem in php strtotime on 32 bit systems is not easy fixable without
introducing any incompatibilities.


--
Best regards,
Michal

http://eventhorizon.pl/
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel