Slash Boxes
NOTE: use Perl; is on undef hiatus. You can read content, but you can't post it. More info will be forthcoming forthcomingly.

All the Perl that's Practical to Extract and Report

use Perl Log In

Log In

[ Create a new account ]

barbie (2653)

  reversethis-{ku. ... m} {ta} {eibrab}

Leader of [] and a CPAN author []. Co-organised YAPC::Europe in 2006 and the 2009 QA Hackathon, responsible for the YAPC Conference Surveys [] and the QA Hackathon [] websites. Also the current caretaker for the CPAN Testers websites and data stores.

If you really want to find out more, buy me a Guinness ;)

Memoirs of a Roadie []
CPAN Testers Reports []
YAPC Conference Surveys []
QA Hackathon []

Journal of barbie (2653)

Monday May 19, 2003
08:30 AM

More module writing

[ #12300 ]
Managed to write considerably more of the Calendar::List module over the weekend. Thanks to davorg's idea, it now looks to see whether a series of modules are installed before performing any date metriculation.

First in the list is DateTime, which is looking to become a very nice module, although currently there isn't a working version available for Win32, so isn't very portable. Next up is Date::ICal, which is very similar and I've been using it more and more over the last year. Then lastly there's the old diehard of Time::Local, though that means we only have a limited date range. I did think about checking for Date::Manip, but seeing as the others are faster I didn't bother. Most of the need for these modules is centred around the need to represent dates in a standard format internally, which then get munged into appropriate formats.

Having discussed with Dave about some aspects of calendars, I thought it might be useful to have a Calendar::Functions module that contains a number of small bitesize routines that save you the time of writing them, should you need them. Seeing as Calendar::List had quite a few, I've already started to write it as a companion to Calendar::List.

Some of these sorts of routines are available in DateTime, Date::ICal, etc, but seeing as they might not be installed and the rest of the module copes without them, do you roll you own, or write a extra layer? I've gone with the latter (primarily because I need to write the Time::Local versions), but it does niggle me for two reasons. 1) It's extra code and 2) there are already far too many date/time routines already. My excuse is that it doesn't try to rewrite the other modules, but acts as an interface between the higher level functionality and the really cool date/time modules. So I suppose it's not so bad.

I'm hoping to get a first release prepared for the end of the week, so with a bit of luck it might hit CPAN before the end of the month.

I also had the thought that Params::Check/Params::Validate could do with a nice wrapper module for CGI params, as I will potentially have to do this anyway to pass my stuff through to whichever module I decide to use. Once I've got Calendar::List out the door, I'll be looking further into these.

The Fine Print: The following comments are owned by whoever posted them. We are not responsible for them in any way.
More | Login | Reply
Loading... please wait.
  • DateTime also comes with a pure Perl implementation that works fine on Win32.
    • On CPAN? The one I got didn't work. It fails to get past make. I have several additional PPM repositories and none of them have a Win32 version either.

      Having done a google search, I noted that several other people have had similar problems, with no effect answer. Perhaps you ought to make a note of the Win32 situation with an appropriate link to a working version in the POD.

      • There's a problem compiling the module, but if you do "perl Makefile --pm" it'll skip trying to compile the XS code, and use the pure Perl version instead. Hopefully the compilation problems will be worked out soon and it'll install normally on Win32 in the next version.