Re: Date methods simplified
| From: | Alan Knowles | Date: | Wed, 22 May 2002 00:41:58 +0000 |
| Subject: | Re: Date methods simplified | ||
| References: | 1 2 3 4 | Groups: | php.pear.dev |
| Request: | Send a blank email to pear-dev+get-6310@lists.php.net to get a copy of this message | ||
Ok, after a bit more examination...
getTime would make more sense as getUtime or getUnixTime ...
the getDay,getSeconds,getMonth all seem a bit of a waste of space - i guess they come from the java port, however in PHP unless the seconds where private, $this->_seconds etc., or when php5 adds private var, the tempation would be to access these directly???
I can think of 3 good reasons to get rid of them
1. less documentation to read through
2. less code to read through
3. less documenation to write/maintain/translate...
and 1 for not
1. BC on applications that use them already...
function getSecond() {
return $this->second <http://docs.akbkhome.com/pearcvs/classes/Date.html#$second>; }regards alan Alan Knowles wrote:
I just realized this was in pear, it looks really nice (and would have saved me a bit of work yesterday if I'd seen it :) anyway - A few ideas another vote adding $date->utime (even if it didnt work for dates outside 70-38...) it will do when we all get 64 bit processors :) - and then I can $seconds =$totime->utime - $fromtime->utime; the setDate method uses scanf to read dates, and then sets the date directly with list($this->year,$this->mont......) = scanf('%4f-.... etc. since you have methods for setMonth(),setDay() etc. would it not be 'usefull'?? for setDate to call the setDay(etc.) methods to validate the data.. and return TRUE/FALSE hence setDay/Month/Date would return TRUE/FALSE if the date was valid or not..... anyway I'm off this morning to add require_once('Date.php') to a few files.... thanks, alan Baba Buehler wrote:Nicolas Hoizey wrote:Hi all, I'm looking at the Date package, and I wonder why addSeconds and substractSeconds are so big. I think addSeconds could be the following: function addSeconds($sec) {This would make Date only valid for dates that are representable in UNIXTIME format, roughly 1970-2038... one of the design goals of Date was a representation that worked for dates outside of the UNIXTIME range. If you were only going to use the UNIXTIME format alone, you'd be better off with the built-in PHP functions. Time in seconds is only used where absolutely required (daylight savings time information) and for compatability with other code that uses the "time-in-seconds" format. As to shortening/optimizing any of the methods... I'm sure there is room for improvement. Date is my "first pass" and I only focused on functionality. If you've got ideas/patches for improvements, please post them or send them to me. baba$this->setDate($this->getDate(DATE_FORMAT_UNIXTIME) + $sec, DATE_FORMAT_UNIXTIME);}