Re: Maintainer of Date_Calc

From: Date: Fri, 10 Aug 2001 14:03:53 +0000
Subject: Re: Maintainer of Date_Calc
References: 1  Groups: php.pear.dev 
Request: Send a blank email to pear-dev+get-1371@lists.php.net to get a copy of this message
Is it possible that you could have 'dynamic' representation of the Date class? For example, in my PHP app, I often have times where I fetch a DATE from MySQL (which comes back in the xxxx-xx-xx format), and then after returning it from a function, that date gets inserted directly in a SQL query. Sometimes the date gets processed (e.g. a week is added to it). Because of this, I end up converting the dates from MySQL to Unix timestamp and passing them back as such. The "client" then either immediately converts to MySQL format or adds an X number of seconds and converts to MySQL format. So in most cases the sequence is: MySQL to timestamp to MySQL. Obviously, the timestamp conversion, both ways, is wasteful on CPU. So the idea is that if the following were done using your Date class (I forget the exact convetions for the interface, but you get the idea): 1 Date x = Date::fromMysql('2001-02-04'); 2 // no manipulation to X 3 $sql .= 'WHERE startdate < \'' . x->toMysql() . '\''; then on line 1 Date would just store the MySQL date itself inside the class (perhaps the 'MySQL representation'), and immediately return that stored string on line 3, without any kind of conversion. On the other hand, if the following were done: 1 Date x = Date::fromMysql('2001-02-04'); 2 x->addMonths(4); 3 $sql .= 'WHERE startdate < \'' . x->toMysql() . '\''; then on line 2 Date would actually convert the stored MySQL date to some sort of useful internal representation (e.g. Date_Calc::dateToDays kinda thing), add four months, then return the internal reprsentation as a MySQL date string on the 3rd line. Also, if the following were done: 1 Date x = Date::fromMysql('2001-02-04'); 2 // no manipulation to X 3 $stuff = x->format('blah'); then on line 3, Date would convert stored MySQL string to whatever internal representation and then format it and return the formatted date. Same can be applied to timestamps, etc. This enables an application to pass around Dates freely, while knowing that things like "lazy representation conversion" can make things faster. azatoth@hem.passagen.se (Erik Hjortsberg) wrote in news:5.0.2.1.0.20010804172440.01b27c60@pop.student.lu.se: > Does anyone know how to contact the maintainer of Date_Calc, Monte > Ohrt? I've mailed him to no avail and I've not seen him on the list... > Anyways, does anybody know any method of converting an arbitary number > of days to a correct date, such as '2001-01-40' => '2001-02-09'? > I've working on a Date-class, the problem is that I wan't to use the > functions in Date_Calc as much as possible, but they contain a lot of > error-checking which is unnecessary. It would be better if instead of > the entity methods in Date using the static methods of Date_Calc the > latter would instead use the methods of Date. The interface of > Date_Calc would be exactly the same, but the speedup of Date would be > significant.

« previous php.pear.dev (#1371) next »