https://bugs.wireshark.org/bugzilla/show_bug.cgi?id=6179
Jim Young <jyoung@xxxxxxx> changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |jyoung@xxxxxxx
--- Comment #9 from Jim Young <jyoung@xxxxxxx> 2011-07-31 18:57:33 PDT ---
Nice enhancement.
I've long depended on the editcap time adjustment feature, but having the Time
Shift feature within Wireshark has definite productivity gains.
One obvious buglet to resolve:
Leading zeros on fractional seconds are not accounted for properly. A
fractional shift such as 0.0000001 actually adjusts time by 0.1. A fractional
shift of 0.000222 adjusts the time by 0.222. (At least this problem manifests
itself on my OS X jhbuild based version).
A couple of comments:
1) I think the "Time Shift" dialog syntax hint should include [+|-]. e.g.
> Time offset in the format: [+|-][[hh:]mm:]ss[.ddd]
2) I also think there should be some way to determine that the timestamps (i.e.
the "Arrival Time") has been time shifted. But I'm not sure how one would
indicate that the time-stamps within the trace file has been
"cooked"/"modified" but not yet saved.
Perhaps a new generated field such as frame.time_shift could be added to the
tree that documents the time shift value that has been applied to the current
trace.
Or perhaps another approach would be to flag the frame.time field with the
PROTO_ITEM_SET_GENERATED macro. This would result in the ("Arrival Time:"
packet detail entries wrapped in "[" "]". But I suspect this approach is
probably too subtle an indication that a Time Shift has been applied.
--
Configure bugmail: https://bugs.wireshark.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are watching all bug changes.
