stuartpb
commented
9 years ago The timestamp precision doesn't really need to be specified if all timestamps adhere to the ISO format, which (apart from the "y10k" problem of four-digit years) will sort properly, indefinitely, with interpolation for any reasonably-precise timestamps.
per the y10k problem (as inherently manifest in the ISO standard), not to tempt fate (ala y2k, which unlike y10k was well within the life expectancies of its architects), and apologies to Long Now, but by the year 10000 this will probably not be the most pressing issue. (I'd honestly be disappointed if humanity doesn't move on from the Gregorian calendar in the next 8000 years.)
(and if your setup really needs to handle years of 5+ digits, because you're doing some kind of test projections or something, you can make an alternative implementation of the logs plugin that applies a numeric sort first.)
As touched upon in #10.
This would use more specific names to denote the different types of field.
I was thinking a plugin could upgrade old formats to new formats by calling, say, timestamped-app-logs and inserting the source "(unknown):", but that wouldn't work for plugins that do define timestamped-sourced-app-logs unless you either did:
so basically with traditional hook semantics, plugins that don't implement the "right" hook (outputting the right format) will get passed over, which is fine with me (and doing the trickery, for situations that (for some reason) can't rectify the problem the way that doesn't bend Plushu's conventions, is ok, kind of like "plushu-read-post-command-opts").
Timestamp could maybe be "millisecond-timestamped", although now we are making a really verbose hook name