At 06:59 AM 11/15/2001, brian moseley wrote: >On Wed, 14 Nov 2001, Aaron Johnson wrote: > > > I see it as an OO interface to CPAN in a way. > >-1. if it ain't broke, don't fix it. the date/time modules >on cpan are completely sufficient. there are many other >areas where cpan has an insufficient or nonexistent >solution. those are the areas where we should be spending >time.
-1 on fixing CPAN fot Date/Time for NOW because it is outside of scope. However, I think it is appropriate to acknowledge CPAN does have a problem with date and time. It's not a clean API and is currently spread amongst several overlapping modules. Date and Time is definitely annoying. This is why we had to write a Date/Time wrapper library (for our WebCalendar product) around both Date::Manip AND Class::Date. Class::Date is probably one of the best right now, but it has to be compiled and is completely unavailable (as of a few weeks ago) from ActiveState PPM -- So it leaves out Win32 users. :( Date::Manip has been around forever, but it's pure Perl and so it is SLOW. My gut feeling is that we should standardize on using one or the other though. And it is THIS that we should vote on before discussing making a standard API. In other words, I would +1 the use of Class:Date as our standard Date/Time module. But if other's feel that Class:Date has some significant deficiencies that cannot be resolved (I think the lack of being compiled on Win32 could be resolved) then we might want to consider at that point extending the P5EE discussion to include a more standard wrapper around CPAN modules for Date/Time consistency. Later, Gunther
