ChatZilla:Timestamps

ChatZilla's timestamp stuff is inconsistent. Braindump go! - Robert Marshall 08:02, 3 July 2006 (PDT)

Current Situation

Display timestamps use a preference with % replacements for y/m/d/h/n/s, defaulting to [%h:%n]. They're displayed using CSS generated content.
Log timestamps use native date/time formatting, hardcoded to use short date and time with no seconds.
View → Show Timestamps toggles timestamp status for the current view and all child views.

The user can't customize log timestamps.
Log file analyzers such as PISG can't figure out what format a log is using.
Display timestamps can't be made to use a 12-hour clock.
Turning timestamps on and off is slow, especially with many views and a lot of scrollback.

Move timestamp formatting to its own function that plugins can mess with if necessary.
Stop using generated content.
Make both log and display timestamps use the native formatter by default.
- Log timestamps should use the same settings they do currently.
- Display timestamps should use time only with seconds.
Add prefs to allow native formatting to be overridden with strftime.
- If possible, make sure old custom timestampFormat prefs are compatible. If not, change the pref name.
Make View → Show Timestamps apply globally, retaining the prefs for people who want it different from view to view.

What should the format prefs look like? Two options:
- A pref for logs, and a pref for display.
- A pref for time, and a pref for date. Logs use both, display uses time only.
Which of the prefs discussed should be hidden?
- "All of them"'s fine by me, maybe hide the formatting ones but keep the ones for timestamps?
What should /timestamps do? What should /timestamp-format do?
Should duplicate timestamps get "collapsed"?
- I think Silver implemented this, not sure.
- Maybe overload on the collapseMsgs pref?
Should we attempt to add a timestamp format "marker" to logs?
- Probably overkill.
- Tell people who use log analyzers to use custom prefs.