The current format is illustrated by the following
examples from Windows and Linux:
Windows example (note the actual precision is 15
milliseconds):
2009-04-12 21:38:11.323000 UTC - 0[9b33c8]: Loaded library Executable (init)
2009-04-12 21:38:11.323000 UTC - 57868[9bb438]: thread exiting
2009-04-12 21:38:11.323000 UTC - 124212[9bb098]: thread exiting
2009-04-12 21:38:11.323000 UTC - 58588[9bbb78]: thread exiting
2009-04-12 21:38:11.323000 UTC - 84644[9bb9f8]: thread exiting
2009-04-12 21:38:11.339000 UTC - 47348[9bb438]: thread exiting
2009-04-12 21:38:11.339000 UTC - 6112[9bb098]: thread exiting
2009-04-12 21:38:11.339000 UTC - 0[9b33c8]: PR_Cleanup: shutting down NSPR
Linux example (please ignore the bug that thread IDs are
printed as negative numbers):
2009-04-12 21:54:59.278954 UTC - -134628864[804b580]: Loaded library a.out (init
)
2009-04-12 21:54:59.285434 UTC - -134632528[8050640]: thread exiting
2009-04-12 21:54:59.285429 UTC - -143025232[8050768]: thread exiting
2009-04-12 21:54:59.291925 UTC - -159810640[80509b8]: thread exiting
2009-04-12 21:54:59.291999 UTC - -151417936[8050890]: thread exiting
2009-04-12 21:54:59.298288 UTC - -134632528[8050768]: thread exiting
2009-04-12 21:54:59.298354 UTC - -134628864[804b580]: PR_Cleanup:
shutting down NSPR
2009-04-12 21:54:59.298290 UTC - -143025232[8050640]: thread exiting
Please consider the following issues.
1. Calendar time (PR_Now) vs. interval time (PR_IntervalNow).
We use calendar time now, which is more human-readable but
may be more expensive (a system call). One issue with
PR_IntervalNow is that it has a platform-dependent unit
(returned by PR_TicksPerSecond()) and it may wrap around
in about 12 hours.
2. Local time vs. UTC.
We use UTC now.
3. Sub-second resolution: milliseconds vs. microseconds.
We use microseconds now. Using milliseconds saves
three characters per log message (which are all 0's on
Windows anyway) but some events may appear
simultaneous.
4. Delimiter: '-' vs. ':' (or even none)
We use '-' now.
Wan-Teh Chang