From: Paul M Foster
> On Wed, Mar 18, 2009 at 11:46:31AM -0400, Bob McConnell wrote:
>>> You also need to be aware that on 32 bit Unix and Linux systems the
>> behavior of mktime() on dates after Jan 18, 2038 is undefined. The 32
>> bit counter overflows early on the 19th, so any value returned is
>> invalid. This is not a problem on 64 bit systems.
>> We ran into this recently because Support was defining "never expire"
>> Today plus 30 years. A couple of sites started reporting problems
>> two months ago.
> This is why I normally never use the time functions in PHP. Instead, I
> wrote a date class that uses Julian days internally and doesn't
> PHP time functions. When I need some odd thing (like the date for the
> end of the week), I just add it as a member to the date class. Plus,
> PHP's date objects are woefully unfeatureful. If someone asks on the
> list for a solution, I can use the PHP time functions for advising
> but I don't personally use them.

Unfortunately, this code was initially inherited from another project
and already had mktime() based date calculations throughout (in 19 of
162 files). I'm the fourth programmer to work with this project and now
have to correct these problems. There are several other programmers who
have to correct it in their projects as well. None of us wrote the
original code, so we are all in the same boat. No matter what we want,
we can't just replace code wholesale because of the testing overhead and
other task priorities. We can only fix it after it becomes recognized as
a problem.

The other issue is that I don't do OOP. After 30 years of writing
procedural code, mostly assembler, PL/M and C, I simply don't see the
point of OO, nor can I justify the additional overhead. I have written
functions that others converted into methods, and occasionally re-use
functions that were written as methods, but have never used a whole

Bob McConnell

PHP General Mailing List (
To unsubscribe, visit:

Reply via email to