Huge thanks to our Platinum Members Endace and LiveAction,
and our Silver Member Veeam, for supporting the Wireshark Foundation and project.

Wireshark-dev: Re: [Wireshark-dev] Bug 491 : time delta behaviour

From: Julian Fielding <jfielding@xxxxxxxxxxxxxxx>
Date: Mon, 12 Mar 2007 21:59:58 +0100
Jeff Morriss wrote:
>Guy Harris wrote:
>> Jeff Morriss wrote:
>> 
>>> What about renaming the current field "frame.time_delta_displayed" and 

>>> name the new one "frame.time_delta"?  That changes the current field 
but 
>>> it sounds a whole lot more intuitive to me.
>> 
>> Or "delta_displayed" and "delta_captured", which means that any 
>> "frame.time_delta" filter would fail rather than filtering something 
>> different from what it did before the change.
>
>Or, as per my comment in bug 491 (which I've just now recalled):
>
>> Another might be to prohibit filtering on this field altogether since 
it's,
>> well, kinda illogical.
>
>I know now (though I didn't know then) that it is possible to make 
>fields not filterable (by making the filter field an empty string) so 
>what about:
>
>- add a new field (with filter "frame.time_delta") which is the time 
>delta to the previous frame in the file
>- keep the display of the time since the previous displayed packet, but 
>make the field is not filterable
>
>?
>
>Normally I'd see the use in not changing semantics for a field, but I 
>don't think the current semantics make any sense at all so I can't 
>imagine it is being used [therefor it's OK to change it].

It makes no sense in a display filter, but it is useful in a colour filter 
or in Edit > Find Packet > By Display filter.

I often use a colour filter to highlight frames with frame.time_delta>x, 
where x is something small. Of course it's only meaningful if the 
displayed frames are all related in some logical way, but that often 
applies because I've used capture or display filters to get such a 
display.

I don't mind a name change, but don't want to lose the present 
functionality.

Julian.