ChatZilla:Timestamps

From MozillaWiki
Jump to: navigation, search

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.

Problems

  • The user can't customize log timestamps without changing system settings, and even then they can't turn on seconds.
  • 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.

Existing code

Proposed changes

  • 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.
  • Move default timestamp formatting to its own function that plugins can mess with if necessary.
  • 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 and migrate.
  • Make View →�Show Timestamps apply globally, retaining the prefs for people who want it different from view to view.

Questions

  • 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?
    • Show display, hide logs.
    • Show all on client, but hide on others.
  • What should /timestamps do?
    • Leave it as-is for now.
  • What should /timestamp-format do?
    • Kill it with fire.
  • Should duplicate timestamps get "collapsed"?
    • Silver already implemented this.
    • 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.