If you travel across the planet, time zones can be confusing. If you get a capture file from somewhere around the world time zones can even be a lot more confusing ;-)
First of all, there are two reasons why you may not need to think about time zones at all:
- You are only interested in the time differences between the packet time stamps and don’t need to know the exact date and time of the captured packets (which is often the case).
- You don’t get capture files from different time zones than your own, so there are simply no time zone problems. For example, everyone in your team is working in the same time zone as yourself.
Further time zone and DST information can be found at https://wwp.greenwichmeantime.com/ and https://www.timeanddate.com/worldclock/.
Set your computer’s time correctly!
If you work with people around the world it’s very helpful to set your computer’s time and time zone right.
You should set your computers time and time zone in the correct sequence:
- Set your time zone to your current location
- Set your computer’s clock to the local time
This way you will tell your computer both the local time and also the time offset to UTC. Many organizations simply set the time zone on their servers and networking gear to UTC in order to make coordination and troubleshooting easier.
![[Tip]](wsug_graphics/tip.svg) | Tip |
|---|---|
|
If you travel around the world, it’s an often made mistake to adjust the hours of your computer clock to the local time. Don’t adjust the hours but your time zone setting instead! For your computer, the time is essentially the same as before, you are simply in a different time zone with a different local time. |
You can use the Network Time Protocol (NTP) to automatically adjust your computer to the correct time, by synchronizing it to Internet NTP clock servers. NTP clients are available for all operating systems that Wireshark supports (and for a lot more), for examples see http://www.ntp.org/.
So what’s the relationship between Wireshark and time zones anyway?
Wireshark’s native capture file format (libpcap format), and some other capture file formats, such as the Windows Sniffer, *Peek, Sun snoop formats, and newer versions of the Microsoft Network Monitor and Network Instruments/Viavi Observer formats, save the arrival time of packets as UTC values. UN*X systems, and “Windows NT based” systems represent time internally as UTC. When Wireshark is capturing, no conversion is necessary. However, if the system time zone is not set correctly, the system’s UTC time might not be correctly set even if the system clock appears to display correct local time. When capturing, Npcap has to convert the time to UTC before supplying it to Wireshark. If the system’s time zone is not set correctly, that conversion will not be done correctly.
Other capture file formats, such as the OOS-based Sniffer format and older versions of the Microsoft Network Monitor and Network Instruments/Viavi Observer formats, save the arrival time of packets as local time values.
Internally to Wireshark, time stamps are represented in UTC. This means that when reading capture files that save the arrival time of packets as local time values, Wireshark must convert those local time values to UTC values.
Wireshark in turn will display the time stamps always in local time. The displaying computer will convert them from UTC to local time and displays this (local) time. For capture files saving the arrival time of packets as UTC values, this means that the arrival time will be displayed as the local time in your time zone, which might not be the same as the arrival time in the time zone in which the packet was captured. For capture files saving the arrival time of packets as local time values, the conversion to UTC will be done using your time zone’s offset from UTC and DST rules, which means the conversion will not be done correctly; the conversion back to local time for display might undo this correctly, in which case the arrival time will be displayed as the arrival time in which the packet was captured.
Table 7.2. Time zone examples for UTC arrival times (without DST)
| Los Angeles | New York | Madrid | London | Berlin | Tokyo | |
|---|---|---|---|---|---|---|
Capture File (UTC) | 10:00 | 10:00 | 10:00 | 10:00 | 10:00 | 10:00 |
Local Offset to UTC | -8 | -5 | -1 | 0 | +1 | +9 |
Displayed Time (Local Time) | 02:00 | 05:00 | 09:00 | 10:00 | 11:00 | 19:00 |
For example let’s assume that someone in Los Angeles captured a packet with Wireshark at exactly 2 o’clock local time and sends you this capture file. The capture file’s time stamp will be represented in UTC as 10 o’clock. You are located in Berlin and will see 11 o’clock on your Wireshark display.
Now you have a phone call, video conference or Internet meeting with that one to talk about that capture file. As you are both looking at the displayed time on your local computers, the one in Los Angeles still sees 2 o’clock but you in Berlin will see 11 o’clock. The time displays are different as both Wireshark displays will show the (different) local times at the same point in time.
Conclusion: You may not bother about the date/time of the time stamp you currently look at unless you must make sure that the date/time is as expected. So, if you get a capture file from a different time zone and/or DST, you’ll have to find out the time zone/DST difference between the two local times and “mentally adjust” the time stamps accordingly. In any case, make sure that every computer in question has the correct time and time zone setting.