Having done this same sort of thing quite a few times before, I agree with ikegami completely. When I discovered Date::Time it solved all of my problems. A little time thinking about *how* to use it...and it took very little time to do thinking given the tools that Date::Time provides... and I've never had to look back.

I also often have issues, especially with cummulative counters, finding the number of "new" or "added" things during a particular time period. Date::Time, again, makes that easy.

So I highly recommend getting to know Date::Time.

ack Albuquerque, NM

You keep mentioning Date::Time which consists entirely documentation of a interface concept. It has with no actual code. I believe you meant DateTime. The later is a well engineered module. It's great at not letting you do something that would be a bug.

If you put each record on one line, then you have something where you can just snip out a section and put in say Excel or other spreadsheet. If the log file record format is well thought out, then you can filter it with other Perl programs and/or use spreadsheet to generate zoomy graphs, etc.

The combo of Perl to do some simple data massaging and then import into Spreadsheet can generate some real zoomy looking stuff and can often be automated with simple macros if format is designed well.

Update: I hope a bit more amplification on a couple points may help you. Sorry if this is too "wordy", but I think content is on target.

It appears that some sort of "fixed field order" record lines (not fixed columns), but lines with a fixed order of data would work well for you, with each date/time record being on one line. Why?

Of course there are lots of variables here that I don't know, and things depend upon your users and who might want a report from your logged data (maybe the boss or some other group in the company, etc). But if you set this up so that Excel can import the log data just as it is, then sometimes users can and will generate their own reports if you just give them the data. You have to decide if CSV file, tab separated, space separated is appropriate or whatever.

Whatever date/time format you decide upon, use something that Excel can understand and it can understand a LOT of these formats.

I'm just suggesting that if you can do something that "empowers the user", they often will do a lot of "zoomy" presentation stuff on their own. If this happens, it is great for everybody! Some accounting types who don't know beans about programming, can do magic with spreadsheets! Then you are providing the data and concentrating on the software stuff and they are doing part of the work for themselves. I hope you are this lucky! That may not happen for you (and probably won't)..but consider that if you set it up this way, then you can do some Excel macro stuff yourself. Don't assume that Perl has to do everything from data generation to fancy pie chart presentation.

Another point is that often seen on Monks, are questions about how to parse a tricky format with a REGEX. Since you are generating the records to begin with, think about how to make this parsing/matching problem "dirt simple" for you to do.

Another thing to consider is that sometimes "exact" precision is not required. What I mean is say instead of "one calendar week", sometimes it is good enough for the last 7 days for which we have data. Every time the "date" string changes, it is a different day. Maybe you don't care if the computer was turned off for 3 days during a week. Maybe you just output the set of data for the last 7 date string changes which might encompass 10 days instead of 7 (maybe plant shut down for a holiday). But for example in that case, there is no "date arithmetic" - you just need to know that the date changed 7 times and that's 7 days of data, etc.