Usefulness of xt_recent's "last seen" and "oldest_pkt" on a tickless system

First of all, this is about the third time I've asked about this subject on this mailing list, and I've never had anybody reply. /taps microphone
Is this thing on?

I have been trying for several months to work out a way to parse the the output of "cat /proc/net/xt_recent/<name of rule>", and return meaningful numbers for the "last_seen" and "oldest_pkt" fields. As best as I can determine, these are just a count of the number of jiffies since boot. However, on a tickless kernel, there is really no well defined number of jiffies per second as far as I can tell - it's going to be a function of how often things need the system to wake up, and will vary from moment to moment based upon the workload of the system.

If this is so, then this calls into question the utility of reporting jiffies to the user - there's no way the user has to relate those values to anything meaningful. It also calls into question the whole idea that a recent rule can meaningfully specify a number of seconds for a packet to be tested, if all that is stored is a number of jiffies.

So, the first question I have is: is there any meaningful way a userspace tool can convert the values reported by /proc/net/xt_recent/* into a wall clock time?

The second question is: if the answer to the first question is no, then why report those values at all? The whole point of a procfile interface is to report data to userspace, but if there is no meaningful way to use that information, what good is it?

The third question is: wouldn't make more sense to capture the actual wall-clock time of a packet, and report that to user space in a meaningful way from the procfile interface? At least report time from epoch in seconds - something that can be manipulated in a meaningful way?