[kronolith] (no subject)

[Samuel Nicolary]

On Wed, 28 Jul 2004, Chuck Hagenbuch wrote:

> Quoting Samuel Nicolary <sam at nicolary.org>:
> 
> > Given the lack of a native full set of date and time functions in the PHP
> > interpreter and the presence of these features in the PEAR Date module it
> > seems to me that any date offsetting should be handled by Date objects.
> > To take this a step further it seems appropriate to represent all date
> > fields handled within the Horde framework and its modules as Date objects.
> > I see framework support for this in form retrieval but it doesn't look
> > like this is being taken advantage of within Kronolith.
> 
> Not fully, no. I agree with Jan that this is probably a good way to go,
> but I'm also a bit reluctant to rely so fully on PEAR Date. I like the
> concept, but I'm nervous about that particular implementation. I did a
> little work on Kronolith_Date as a potential alternative; that could
> theoretically be beefed up and put into the framework instead.

I agree with your assessment of PEAR Date - I already had to put a hack in
place in my code to make up for its weak (I am being kind) handling of the
daylight saving flag and I was thinking about doing some work on it to
contribute back to the project but I think that an extended Kronolith_Date
class with some of the functionality from PEAR Date methods implemented
would do the trick.

I hadn't looked that closely at the class yet but it has all the
beginnings.  What about pulling the Kronolith_Date class into the larger
framework (Horde_Date?) for use in other modules though?  I can see the
potential need in nag, whups, hermes and thor to name a few.  I can also
imagine integration with the Form framework package.

-- 
Sam Nicolary