On Wed, Mar 18, 2009 at 12:57:39PM -0400, Bob McConnell wrote: > 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. I feel your pain. Been there, done that. T-shirt in drawer. > > 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. > You know, I'm gonna start a programmer blog to talk about things like this (as soon as I finish the blog software, in progress now). I'm sympathetic. I also come from a procedural background, and frankly don't see that the OO hype has lived up to its promise. I see two reasons to use OO under select circumstances: First, namespaces. The more routines you have in a given program, the more likely you are to have function name collisions. OO helps with that. The other thing that comes to mind is that objects can have embedded value members which get shared between the various class methods. Meaning I don't have the overhead and hassle of having to pass those values around to all the functions involved. I don't know that objects have any noticeable overhead versus functions. But I'm pretty judicious about the use of objects-- only if that's the "best" solution for a given problem (best in *my* opinion). Paul -- Paul M. Foster -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
