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.