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" as >> Today plus 30 years. A couple of sites started reporting problems about >> 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 consult > 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 them, > 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 class. Bob McConnell -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
