Hey Gerald: Im not sure if your monitoring this feed or not, but we met at Sharkfest '17 and discussed the MAC address issue, which you took care of straight away, thank you for that. We discussed another issue concerning my inability to computate time. I really find it difficult to find problems in trace files that have occurred in other times zones. Especially in the west coast, maybe it would be easier if I was on the West Coast looking at trace files from the East coast, it might make more sense to me. I call myself time challenged. Well we talked about setting the timezone in a command windows to the time zone in which the trace was made. This did work in windows XP, and it still does in never version of windows however, its a global change now. Advisors that I work with that read trace files use monitoring systems that uses time indexing to record voice calls and keystrokes that might not like a global change like that. Their stats are based on the time they take a call, analyze an issue and wrap up a call. If a time zone change is made, the system may record a longer or shorter time instead of the actual duration of the call. If you recall, I asked if you could do me a favor and add an offset setting to the UTC time of the capture so that the local time that the issue occurred can be seen when viewing the trace with Wireshark. I remember you discussing some things with Anders, but you then suggested the command window idea, which we can not do or should not do, I'm not sure which one. Actually Gerald, I want to give this a hack myself, but I am buried with tractor, laptop and cell phone repairs to the point I cant even get to my own repairs during the off time. I wouldn't even know where to start. Thank you Paul asked 06 Jul '17, 11:19  Pauli |
One Answer:
This did work in windows XP, and it still does in never[sic] version of windows however, its[sic] a global change now. I just tried this in a Windows 10 command prompt and it didn't appear to be a global change to me. I am also on the East coast and just captured traffic with local time of 17:05. After setting the timezone according to the format specified here for Pacific Daylight Savings Time, the packet time was adjusted to 3 hours prior at 14:05, just as expected: My system time remained on Eastern Daylight Savings Time during this test. answered 06 Jul '17, 14:11  cmaynard ♦♦ |
Curious why you aren't using the "Time Shift" feature already built into Wireshark.