Re: Maintainer of Date_Calc
| From: | (Oleg Rekutin) | 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.