Updated PEAR::Calendar today with v0.52, mainly containing Lorenzo’s hard work (many thanks!). Reminded again how important it is to have a decent PHP unit test framework (plus writing tests in the first place) – would be more or less impossible to maintain PEAR::Calendar without it.
There’s still some requested features outstanding for PEAR::Calendar, such as adding some easy way to determine whether a date is a weekend (coming up soonish) but it’s reaching the point where all the essential functionality is there. Will be interesting to see if it ever leads to alternative “calculation engines” being written – in theory it should be possible to build a Chinese or even a Tolkien calendar with it – “just” a matter of implementing the interface.
The big issue is performance though – it’s got to get faster. Particularily for a Calendar that’s “hooked up” with dynamic data, caching can be tricky so it needs perform well even when “re-executed” on every request.
Right now it’s not exactly slow but internally it can (depending on what you’re doing) generate a lot of function calls, particurily when using decorators. Some of these calls could be bypassed by accessing object properties directly.
Otherwise still pondering some kind of internal caching using serialization. One problem here is unserializing a string containing objects can often be slower than reinstantiating them directly from PHP – in this specific case it may be possible to gain a little though by bypassing the date related math that creates the objects. Another approach there might be code generation (haven’t really thought seriously about that yet). The other problem may be fundamental to the way dates can be selected – the selection “merges” with the normal calendar data structure but will need to be separate for caching purposes – may need an alternative selection mechanism.
Anyway – will get there eventually and with PEAR::Date_Holidays looking like it’s going to be accepted, PEAR’s Date and Time collection starts to look quite attractive hopefully.
Related posts:
- Free PHP Webinar: How to Increase Performance with Caching Zend are running a free webinar today, with a live...
- Cross-browser JSON Serialization in JavaScript JSON serialization can be incredibly useful, but few browsers support...
- Why Opera 10’s User Agent Smells Bad The user agent in the soon-to-be-released Opera 10 will report...
please write a tutorial for it!
August 17th, 2004 at 2:16 am
OK – will add that to the todo list. There is some documentation online here plus plenty of examples that come with it. Perhaps the most useful example is this one Lorenzo added – shows how to build an event calendar with it.
August 17th, 2004 at 3:19 am
Awesome! Thanks Harry and Lorenzo. Ever since I discovered PEAR about 3 months ago, the Calendar package has been one of my favorite and oft used packages. Excellent work! And keep it up, I know we all appreciate it.
August 17th, 2004 at 9:32 am
Does it support Hijri(Lunar based),Jalali(Sun based) and Hebrew Calendars. Also How well does PHP support I18N? Does it support BiDi? Those aforementioned Calendars are usually done right -to-left.
August 17th, 2004 at 11:56 am
Maybe build memcached support or at least some sort of caching hooks so the user can implement there caching method of choice
August 17th, 2004 at 1:11 pm
Well not right now but in theory it could. The calendars would need to have some quantity which can be equated to the calendar “units” of year, month, week, day, hour, minute and second. All the real math happens in the engine classes, even determining (what are normally absolute) values such as the number of days in a week. So (in theory) all you need to do is perform the required calendar math while implementing this interface. I say in theory because it hasn’t been done yet, other than the two existing engines, one using Unix timestamp-based calculations and the other using PEAR::Date. My guess is the notion of a week may be problematic is some cases but that can be fixed.
Not so well. For basic i18n you can change locales as with this example. Dealing with stuff like character sets and unicode is not natively handled – you have to start messing with stuff like the mbstring extension.
(Update) You may also be interested in this http://pecl.php.net/package/fribidi…
Things may be getting better soon – an reads on the subject; http://www.zend.com/lists/php-dev/200303/msg00656.html. Otherwise best to check in at the php.i18n mailing list http://news.php.net/group.php?group=php.i18n.
That part shouldn’t be too much of a problem. PEAR::Calendar doesn’t itself generate any output – just generates a the elements of the calendar as a data structure for you to loop over and render whatever you want. Would probably just be a case of concatenating a string.
August 17th, 2004 at 3:24 pm
Perhaps some hooks is the best way – do with the objects as you like (and saves me having to reimplement stuff done elsewhere). Thanks – reckon I’ll do that.
August 17th, 2004 at 3:27 pm