-
Notifications
You must be signed in to change notification settings - Fork 35
feat: add include-timestamp flag #148
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Conversation
parse/process.go
Outdated
| } | ||
| fmt.Fprint(option.w, e.Output) | ||
| if e.Output != "" && option.includeTimestamp { | ||
| fmt.Fprint(option.w, e.Time.Format("2006-01-02T15:04:05.000000-07:00")+" "+e.Output) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Curious, how did you land on this timestamp format?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I was implementing the timestamp feature to match the format shown in the JSON output of the issue (2025-05-05T14:14:46.965151-04:00). The goal was to provide consistent timestamp formatting when using the -include-timestamp flag, similar to what's mentioned in the issue.
I went with a custom format string, but I realize now that might not have been the best approach. Would you prefer I use one of the standard time format constants like time.RFC3339Nano, or do you have a different format in mind for this output?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
When I filed the issue I think I just copied that over from GitHub workflow logs.
I bet we can use one of the time package formats. WDYT?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I wonder if we need tha much granulrity, do you think time.RFC3339 would be good enough (to reduce the line length).
Last question :)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
that can be a good option , it would reduce the length of the output by 7-8 characters, making it easier to view on a terminal. Updating the PR accordingly.
|
I merged some other PRs in the meanwhile, mind resolving the conflicts? |
resolved |
mfridman
left a comment
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks!

What
-include-timestampflag to prepend timestamps to follow output lines.e.Time.Format()methodwithout
-include-timestampflag-follow-follow-verbose-follow-outputwith
-include-timestampflag-follow-follow-verbose-follow-outputWhy
closes #141
Test