Re: Re: Maintainer of Date_Calc

azatoth@hem.passagen.se (Erik Hjortsberg) wrote in news:5.0.2.1.0.20010811000657.01b40c90@pop.student.lu.se: > 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. Ehh, I guess range checking forces conversion. Thing is, I had to do a lot of Date_Calc intensive code today (and found like three bugs in it, was it tested thoroughly at all?), and ended up doing silliest conversions between days and dates. It was very convenient for my algorithm to just add X days to the "days from unspecified epoch" and squeeze a yy/mm/dd date out of that when necessary. However, to use functions such as beginOfNextMonth and NWeekdayOfMonth and nextDayOfWeek, I had to specify the dates in three separate year/month/day arguments, which meant converting days value with daysToDate to something splittable (e.g. %Y-%m-%d) into three separate variables, then passing that on to NWeekdayOfMonth. However, since the result ultimately had to be in days, NWeekdayOfMonth and such were asked to return the result as days from epoch, which, if you looked at the code, meant that the internally-used number of days was converted to separate yy/mm/dd, transferred to dateFormat, which then converted it back to days. Basically, quite a mess, quite a waste of resources. Ideally, I would be dealing with Date objects, not caring about the interal representation, but only caring about creating a Date from some format and displaying a Date in some format, and being able to add 40 days or do stuff like Nth weekday of month by manipulating and passing in only the Date objects, comparing Date objects easily, etc. > I have however been toiling away at another issue that has been bugging > me for a long time: > _locale setting_ Sorry, can't be of help on this issue.