Re: Re: Maintainer of Date_Calc

At 14:03 2001-08-10 +0000, you wrote:

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.

Well, I see your point here, but it would be hard to implement it. The reason for this it that the contructor for Date looks like Date($year = null, $month = null, $day = null). Reason being that it's impossible to misinterpret (which Date($strDate) would be). Also, it always does range checking, thus $date = &new Date(2001, 1,40); is valid and would return an object with the date 2001-02-09. I have however been toiling away at another issue that has been bugging me for a long time: _locale setting_ strftime() is all nice and dandy, the problem is however that the same locale on different systems turns up different, if it turns up at all! PHP need a common independant locale-setting! Thus: Date::SetLocale('de_DE'); etc.. Now, I took a look at /usr/share/i18n and found some locales. But there must be a better resource, such as a web-page. Anyone know? I handled locales through adding a directory, {PEAR}/locales. I've also moved most of the core logic from Date_Calc into Date and made Date_Calc use objects of Date instead (which in most cases brought a speedup as it could avoid all the validation). The format() method of Datetime is also fully compliant with Opengroups strftime() (except for timezone as I haven't found out which is the proper way strftime() want it handled). I'll clear up the code and post it soon. /erik hjortsberg