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: http://wwp.greenwichmeantime.com/ and http://www.timeanddate.com/worldclock/.
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.
![[Tip]](wsug_graphics/tip.png) | 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! |
| Tip! |
|---|---|
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, EtherPeek, AiroPeek, and Sun snoop formats, save the arrival time of packets as UTC values. UN*X systems, and "Windows NT based" systems (Windows NT 4.0, Windows 2000, Windows XP, Windows Server 2003, Windows Vista) 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. "Windows 9x based" systems (Windows 95, Windows 98, Windows Me) represent time internally as local time. When capturing, WinPcap 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 Microsoft Network Monitor, DOS-based Sniffer, and Network Instruments 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 |
An 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.