search

schweikert / fping

High performance ping tool
https://fping.org
Other
1.01k stars 250 forks source link

Predefined various timestamp formats #321

Closed gsnw closed 2 months ago

gsnw commented 3 months ago

This extension allows you to change the format of the timestamp when using fping -D -l 127.0.0.1. Example: fping -D -l --timestamp-format=ctime 127.0.0.1

Issue: #310

coveralls commented 3 months ago

Coverage Status

coverage: 85.469% (+0.4%) from 85.117% when pulling d7a1dce8ffc632b4b3b2d4b06be9026c8e156953 on gsnw:issue/310 into 2f2ff0bd2c38c911cfe659bd65dc494e8dd0bc2b on schweikert:develop.

auerswal commented 2 months ago

Please also consider adding a description to the man page, i.e., fping.pod. Thanks!

auerswal commented 2 months ago

I am not so sure any more, especially regarding reltime. With dmesg, --time-format=reltime provides relative time stamps for short time differences, and absolute time stamps for longer gaps, e.g.:

[Jun 9 21:17] …
[ +21,801486] …
[  +0,000004] …
[  +0,000004] …
[  +0,000002] …
[  +0,000001] …
[  +0,091934] …
[  +0,000003] …
[  +0,000002] …
[  +0,000002] …
[  +0,000001] …
[  +0,000004] …
[  +0,574391] …
[Jun 9 22:54] …

Perhaps we should leave out reltime for now?

And a nit: both date --iso-8601 and dmesg --time-format=iso print the timezone offset with a colon between hours and minutes (HH:MM). The %z format specifier does not include the colon, but I did not see a better format specifier in man strftime.

(As another example, GNU date has two quite similar "named" time format options where the output differs mainly with the character between date and time, either a space or a T: date --rfc-3339=s and date --iso-8601=s [--rfc-3339 does not use the locale settings, --iso-8601 does, but fping does not use locale settings (IMHO fping is better in that regard)].)

gsnw commented 2 months ago

The formats are not perfect. I have now turned reltime into rfc3339, even with the knowledge that the format may not be one hundred percent perfect. However, it corresponds to the example from the ticket.

[1] https://medium.easyread.co/understanding-about-rfc-3339-for-datetime-formatting-in-software-engineering-940aa5d5f68a?gi=fc35d513c0fd

auerswal commented 2 months ago

We haven't talked about the process for merging pull requests yet. I would be willing to merge this pull request next weekend, unless there are objections. Is that OK?

gsnw commented 2 months ago

The last github merges were probably done with rebase. Everything has advantages and disadvantages.

All my pull requests are always based on the current state of develop and I always try to do a rebase on all branches in my repository when the develop branch changes here.

So I would prefer rebase and merge

auerswal commented 2 months ago

Ah, I see, that is one of the options shown when clicking the arrow next to Merge pull request. I think I (slightly) prefer that option too, because automatic merge commits add some noise, but only little information. I'll go ahead and do that, thanks!

(For the record: I do not like the Squash and merge option, I prefer to keep the individual commits.)