ChatZilla:Timestamps: Difference between revisions

From MozillaWiki
Jump to navigation Jump to search
No edit summary
Line 4: Line 4:
*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.
*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 [http://lxr.mozilla.org/seamonkey/find?string=nsDateTimeFormat native date/time formatting], hardcoded to use short date and time with no seconds.
*Log timestamps use [http://lxr.mozilla.org/seamonkey/find?string=nsDateTimeFormat 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.
*''View →�Show Timestamps'' toggles timestamp status for the current view and all child views.


==Problems==
==Problems==
Line 14: Line 14:
==Existing code==
==Existing code==
*ReadMe's [https://bugzilla.mozilla.org/attachment.cgi?id=213994&action=edit JS strftime()].
*ReadMe's [https://bugzilla.mozilla.org/attachment.cgi?id=213994&action=edit JS strftime()].
*Silver's ex-0.9.68.6 stuff (not sure of status).
*Silver's ex-0.9.68.6 stuff.


==Proposed changes==
==Proposed changes==
*Move timestamp formatting to its own function that plugins can mess with if necessary.
*Stop using generated content. '''✓'''
*Stop using generated content.
*Make both log and display timestamps use the native formatter by default. '''✓'''
*Make both log and display timestamps use the native formatter by default.
**Log timestamps should use the same settings they do currently. '''✓'''
**Log timestamps should use the same settings they do currently.
**Display timestamps should use time only. '''✓'''
**Display timestamps should use time only with seconds.
*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.
*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.
**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.
*Make ''View →�Show Timestamps'' apply globally, retaining the prefs for people who want it different from view to view.


==Questions==
==Questions==
*What should the format prefs look like? Two options:
*What should the format prefs look like? Two options:
**A pref for logs, and a pref for display.
**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.
**A pref for time, and a pref for date. Logs use both, display uses time only. '''✗'''
*Which of the prefs discussed should be hidden?
*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''?
**"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? What should ''/timestamp-format'' do?
*What should ''/timestamps'' do? What should ''/timestamp-format'' do?
*Should duplicate timestamps get "collapsed"?
*Should duplicate timestamps get "collapsed"?
**I think Silver implemented this, not sure.
**Silver already implemented this.
**Maybe overload on the ''collapseMsgs'' pref?
**Maybe overload on the ''collapseMsgs'' pref? '''✓'''
*Should we attempt to add a timestamp format "marker" to logs?
*Should we attempt to add a timestamp format "marker" to logs?
**Probably overkill.
**Probably overkill.
**Tell people who use log analyzers to use custom prefs.
**Tell people who use log analyzers to use custom prefs.

Revision as of 20:23, 12 August 2006

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? What should /timestamp-format do?
  • 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.