Bug 28429 - X server logs need human-friendly timestamps
Summary: X server logs need human-friendly timestamps
Status: RESOLVED MOVED
Alias: None
Product: xorg
Classification: Unclassified
Component: Server/General (show other bugs)
Version: unspecified
Hardware: Other All
: medium normal
Assignee: Xorg Project Team
QA Contact: Xorg Project Team
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2010-06-07 12:48 UTC by Matej Cepl
Modified: 2018-12-13 22:23 UTC (History)
1 user (show)

See Also:
i915 platform:
i915 features:


Attachments

Description Matej Cepl 2010-06-07 12:48:15 UTC
So, there are now logs in Xorg.0.log (http://cgit.freedesktop.org/xorg/xserver/commit/?id=d2322b6309bf15a45002b42e7e6ba3d6b5bfa932), so bug 25668 and bug 26180 as they stand could be closed IMHO, but miliseconds / 1000 are not exactly easy to read for humans.

-- some more comments from the downstream bug (https://bugzilla.redhat.com/show_bug.cgi?id=582340):

I agree. I'm trying to understand a bug causing Xorg to crash and it would be
more helpful for timestamps to be easier to read. It looks like seconds since
last boot. Even if they stick with seconds as the time stamp, calendar time
(seconds since the epoch) would be more useful since it can be easily converted
to an absolute time without having to figure out when your computer was last
switched on.    
It looks like the X server has started to timestamp its log entries, but
unfortunately this is just in the format of a decimal number.  Making this
human readable would help enormously in debugging problems where log entries
need to be temporally correlated with a stimulus.
Comment 1 Alan Coopersmith 2010-06-07 12:58:11 UTC
Unfortunately, human friendliness is limited by the functions that can be
safely called in a signal handler, which prevents use of strftime().

It would be nice if the log started out with a strftime() output so you could
then calculate later timestamps from the delta though.
Comment 2 Dmitry Bolkhovityanov 2015-12-10 09:18:28 UTC
(In reply to Alan Coopersmith from comment #1)
> Unfortunately, human friendliness is limited by the functions that can be
> safely called in a signal handler, which prevents use of strftime().
> 
> It would be nice if the log started out with a strftime() output so you could
> then calculate later timestamps from the delta though.

Re-entrance safety is understood, but why log RELATIVE timestamps instead of ABSOLUTE (since 1970-01-01 00:00)?

Relative timestamps are almost useless, while absolute ones can be easily converted to human-readable form by "date -d @SECONDS_SINCE_EPOCH".
Thus, absolute timestamps are much more sane.
Comment 3 GitLab Migration User 2018-12-13 22:23:33 UTC
-- GitLab Migration Automatic Message --

This bug has been migrated to freedesktop.org's GitLab instance and has been closed from further activity.

You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.freedesktop.org/xorg/xserver/issues/399.


Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.