All the Perl that's Practical to Extract and Report

Time::Tiny 0.01 released.

Alias on 2006-09-04T06:29:18

I've just released Time::Tiny to the CPAN. It should appear on your mirror shortly.

This is the second in a series of three date/time Tiny modules.

In the Time::Tiny case, it is intended for parsing and generating ISO 8601 compatible time objects, but without the ability to do any significant manipulation to them.

To make up for this, as for Date::Tiny, if you have DateTime installed, you can use the DateTime method on a Time::Tiny object to get the equivalent DateTime object.

This leaves only DateTime::Tiny, the third in the series, to be written.

But this one might take a little while to happen because, like a good CPAN citizen, I'm going to be consulting with the DateTime people first, since I'd be stomping on their namespace.

I've also done another round in the neverending task of upgrading old modules to meet newer, better, ways of doing things.

This time around I've upgraded Module::Install, and done some test scripts cleaning, on about a dozen modules. I've also pulled another half dozen modules from the old CVS repository to the new SVN one.

As a side effect, my Kwalitee should receive a nice boost, to make up for the sheer boringness of module tidy ups.

Why?

Matts on 2006-09-04T14:31:18

Can you give a bit more info as to what use these two modules are? Looking at the source, all they do is store year/month/day/hour/min/sec and give one shortcut for printing those out.

The docs make the excuse that loading time modules takes 3-4MB (only true for DateTime - try something lighter like Date::Class or Time::Piece), but for *::Tiny to do anything useful it looks like you'd have to do that anyway.

I (for obvious reasons) totally disagree with the flamebait in your docs about how DateTime.pm is the only module to get date/time manipulation right.

Re:Why?

Alias on 2006-09-04T22:11:14

I recently worked on an soft-realtime Perl application (using POE) that dealt heavily with dates and times. Not manipulating them, but they had to be parsed and potentially converted between formats.

What I found was that quite a significant amount of work was having to be done just to create the DateTime objects, far more than I was comfortable with.

And yet the data did not require that level of rigour, I wasn't going to be doing anything with the dates, just holding them in memory, possibly converting to a different format, and possible dumping them back out later in the same of a different format.

What I needed was an extremely light, very quick to parse, implementation of a simple data object for date/time/datetime that I could use when speed and lightness were essential.

But having something like that disconnected from DateTime entirely made things difficult for the two places I needed full DateTime logic, and compromised the concept.

Hence the light implementation, with a optional converter to a DateTime object.

I would expect these modules to be used in those scenarios, time-critical or speed-important applications, where no significant manipulation needs to be done, but you still want a sane object form for a date/time/datetime.

As for DateTime being the only module to get it "right", perhaps the term "comprehensive" is better. I've hit various limitations with various date and time modules over the years (and I've written one of my own, a fork of Time::Piece under a previous name) and I never felt they were comprehensive enough to be the One True Solution.

And after doing a lot of date and time work, I've eventually reached the opinion that DateTime is the Right approach to the problem.

Re:Why?

Alias on 2006-09-04T22:11:52

Further, I should note that DateTime is also cross-platform and works on Win32 :)

*hint*

Re:Why?

Matts on 2006-09-04T22:23:23

I agree with the comprehensive thing. Perhaps better wording is required in your module docs :-)

I guess I'm lucky enough to have never really needed that much comprehensiveness. 4MB just to load one damn perl module (never mind the hassle of installing the thing) is just asking too much.

Re:Why?

Alias on 2006-09-04T22:40:44

Well, I've never had a problem installing DateTime, it's been just fine.

The only problem was on Windows, and the DateTime guys have fixed that now.

But yes, it is expensive. Which is why the Tiny modules exist.

And while I have your attention, any chance of getting some small releases of the modules you have commit on (that I mentioned a few posts ago).

The bugs are tiny things, but it would help us out a LOT to have some of your high profile modules working on Windows.

Re:Why?

Matts on 2006-09-04T22:55:10

Time::Piece and anything else?

Re:Why?

Alias on 2006-09-04T23:16:55

Time::Piece and DBD::SQLite. Both have only one niggly test bugs blocking them.

The specific bugs causing the problem are on win32.perl.org

http://win32.perl.org/wiki/index.php?title=Problem_Modules

Re:Why?

Matts on 2006-09-05T18:20:49

OK, Time::Piece updated - can you test please?

I'll try and get around to DBD::SQLite later today.

Re:Why?

Alias on 2006-09-07T15:32:57

The #win32 folk are telling me fail, because of "%V" ?

Just double checked and not working here either.

I'm CC'ing you on the particular failure.

But it's not tiny!

mugwumpjism on 2006-09-08T12:22:31

Each object you create has one SV, one HASH, up to eight HEKs, looks pretty heavy. Compare with Date::Manip where you are looking at a single PV for the important part, which is the ISO-8601 form.

Re:But it's not tiny!

Alias on 2006-09-08T13:33:47

The "Tiny" part isn't necesarily a description of the objects that you create, but rather the size of the codebase to load into memory.

  Date::Manip - 4500k
  DateTime - 2500k
  Time::Tiny - 140k

So while Date::Manip might have a slightly smaller object size, it's a monster to get into memory in the first place. Time::Tiny has a 4+ meg headstart.

All of the ::Tiny modules were created because of similar modules.

Config::Tiny vs Config::Simple and Config::General

CSS::Tiny vs CSS

And so on...

Some may say that it's only 4.5 meg of RAM, and computers have tons of RAM these days, but 5 meg here and 5 meg there and pretty soon you're talking about some real resources.