Item993: Log is (too) inaccurate

The logfiles currently use the TWiki date/time "standard" viz dd Mmm YYYY - hh:mm. This causes a number of problems:

• The date is not parseable by typical date parsing tools, such as Time::ParseDate
• The date is inaccurate, being rounded to the nearest second. This makes the log almost useless when deciding which of two events happened first.
• There is no record of the timezone, which makes comparing logs between sites in different timezones difficult

I propose that the event log dates be changed to ISO 8601 format YYYY-MM-DD HH:MM:SS

Note that Foswiki::Time::parseDate is documented as parsing this format, so as long as logfile users have used this API the change should be seamless. Statistics doesn't use the date, so should be robust.

-- CrawfordCurrie - 05 Feb 2009

After a discussion with Babar and Sven, we have agreed that moving to a proper logger is a better long term approach. Babar is researching.

-- CrawfordCurrie - 05 Feb 2009

Ok, so after asking a few mongers, here is what they answered:

• CPAN:Log::Log4perl - it's the new hype, and according to their FAQ, it's pretty robust and simple to use
• CPAN:Log::Dispatch - seems also pretty powerful, but less than the one above.
• CPAN:Unix::Syslog - interface to syslog. We don't really want to do that, as some of our users aren't root (poor them).

Honestly, from the 2 above, it's more a matter of taste. As I won't be the one to code the changes, I will only recommend CDot to look into them. If they don't fit your needs, explain why, and I will look for some other ones. But they seem pretty generic to me tbh

-- Babar - 05 Feb 2009

I sure hope you guys are not planning to introduce a new not-included-with-standard-perl-CPAN dependency that installers have to fight with just to make a f**king log. If it is a pure perl thing that we can include in the distributed CPAN like we did with Session then I have no worries.

Do I misunderstand the intend?

Why complicate something that is very simple? A log is writing plain text to a plain file.

Why not just implement the simple change that was proposed in the first place?

-- KennethLavrsen - 06 Feb 2009

Keep your hair on. I require two things: (1) accurate times on log events (2) an interface that allows me to iterate over log events.

The reason for the accuracy requirement is that the only record of a rename currently held is in the log. Accurate timing of other events can be a big help to debugging, too. The requirement for the interface is to support plugins that process the logs e.g. statistics, auditing etc.

I have looked at the CPAN modules and none fite the bill. They all provide over-complex interfaces for recording events, but none standardise the replay of the events, which is the hard bit. So I have written a small pure perl module that can - if desired - layer over one of the CPAN loggers, or it can use files compatible with the existing ones (though with more accurate dates).

-- CrawfordCurrie - 06 Feb 2009