FAQ: What is the time zone and time format used in zenon Software Platform products and what needs to be considered?

FAQ: What is the time zone and time format used in zenon Software Platform products and what needs to be considered?

When you ask someone what the time is, they'll usually be able to tell you. But when you ask them what date and time sunrise was yesterday in a different country on a different continent, in a different hemisphere it gets less easy. Terms like GMT (Greenwich Mean Time), UTC (Coordinated Universal Time ), local time, zulu time, time zone, summer time, winter time, international date line and daylight savings are being used.

For the correct analysis of an issue that occurred following a certain event, it is important to understand date and time usage in the operating system and computer software. 

First look at some basic principles.

Timezone concept
The world is roughly divided in roughly 24  time zones. When you travel to the east of Greenwich, a place in England where some smart people quite a while ago defined the prime meridian, the sun rises earlier. When you travel to the west of Greenwich, the sun rises later. About every 15° in longitude there is a 1 hour difference in dusk / dawn. The time in Greenwhich is called GMT or UTC.

However time zones do not strictly adhere to these 15°, they often are adjusted to national and international borders. A standard timezone is defined by the offset to UTC. The standard timezone for Brisbane in Australia for example is UTC+10. The standard timezone for Honolulu (Hawaii, USA) for example is UTC-10. The UTC offset is not always counted in full hours. The standard timezone for India for example is UTC+5.5.

Traveling
When you are traveling and visit a site for troubleshooting, remember to adjust your computer's timezone. Never adjust the actual date/time itself!

Daylight savings
When we speak about standard time, this always is standard time or winter time. Some countries change the clock 1 hour ahead in spring, and again one hour back in autumn. Around the world today, this time change in most cases is exactly one hour.

When the time is changed one hour ahead, it is then referred to as Daylight Savings Time, abbreviated DST. The Offset to UTC increases by one hour. Sometimes this is also referred to as summer time or Daylight time.

In some countries, individual states decide whether to use daylight savings or not. The day on which the time is adjusted, is not defined universally.

Hemisphere
Seasons are opposite in the northern and southern hemisphere. Winter in Europe means Summer in e.g. Southern Africa. This also means that when it is autumn in Vienna and the daylight savings time ends, the daylight savings time in Windhoek Namibia is about to start or has just started.

Time format
Time is displayed in different formats. The 24 hour time format counts from 0 to 23, where e.g. 22:00 is ten in evening. The 12 hour format counts from 12 to 12, where ten in the morning is written as 10:00am, and 10 in the evening is written as 10:00pm.

Midnight and noon
Midnight is the time of the day when the date changes over to the next day. However midnight is subject to debate. With a 24 hour format, 23:59:59 is defined as one second before midnight and 0:00:00 is defined as midnight and usually considered the start of the next day. However sometimes also 24:00:00 may be used for the instant before midnight, and 0:00:00 as the instant after midnight on the next day.

With 12 hour format, midnight usually is considered as 12:00 midnight and noon is considered 12:00 noon.

12:00am midnight and 12:00pm noon in fact do not really exist. 0:00am is the instant after 12:00 midnight happened.  12:00 pm is the instant after noon happened.

Time stamp in the zenon Service Engine
The time stamp in the Service Engine is shown as the local time. Internally the Service Engine uses UTC time.

The time zone for the local time, and the time format used in the Service Engine, is taken over from the Windows timezone settings and Windows regional settings. If for example you need to display the alarm list in 24h format, you need to change the regional settings of the operating system accordingly.

Timestamps in exported files contain a local timestamp of the PC where the export was performed in the format corresponding to the Windows regional settings.

T_Intern
All variables in the zenon Service Engine have a timestamp corresponding to the last value or status change. For most PLCs and drivers, this timestamp is the time when the driver in the zenon Service Engine detected the value change after reading from the PLC. Variables will have the T_Intern statusbit set.

T_Extern
Some PLCs use protocols that support timestamped data. In this case the driver may use the timestamp that is provided with the value change information from the PLC, instead of applying a timestamp when the value change was detected or received. When the timestamp of a variable is received from the PLC, variables will have the T_Extern statusbit set.

T_STD
This statusbit at the varible indicates that the timestamp is standard time (winter time).

Time synchronization with server client in the network
By default, a Service Engine client will synchronize the time with the time of the Service Engine server. The time synchronization considers the time zones. With a server in UTC+2 and a time of 10:00:1 a Service Engine client started in timezone UTC+10 will set the system time to 18:00:01. The computer clocks are synchronized when the time difference is too big. If necessary, time synchronization in the zenon network can be disabled, however it must be guaranteed that the computer clocks are accurately synchronized with other external methods, like a GPS clock and a time server.

Time synchronization supported by protocols
Some protocols support time synchronization of the time of the PLC with the time of the PC and in some cases also viceversa. The time of the PLC may automatically be synchronized when the PLC requests it from the driver connecting to the PLC.

External time synchronization
Time stamp in the zenon Engineering Studio
The time stamp stored internally by the Engineering Studio is mostly UTC. Some modules like PFS and EMS store local time.

Windows file timestamps
Files in Windows can have one or more timestamps. When you look at the time stamp of a file in File Explorer on the local computer, normally the date and time that the file was modified is shown, according to the local time on the computer. When you view the time stamp of the same file through File Explorer via a network share on a computer configured for a different timezone, the time stamp appears different, as again the local time is used. The same file may therefore even show a different modified date on different computers.

Timestamps in log files from the diagnosis server / diagnosis viewer
The time stamp for an entry in the diagnosis viewer is always displayed in UTC. It is therefore possible to compare two events that occurred on two computers in two different timezones. When comparing entries in the log files of the diagnosis server with e.g. information that the customer provided, or information collected from other sources like the Windows Event log, or the Chronologic Event List, or the settings for time related actions in the zenon Engineering Studio, it is important to know what UTC offset is applied to the information provided.

Timestamp in crashdump file name / *.txt crash files.
The time stamp of a crash dump file (modified file date) is shown in local time. The time stamp in the file name corresponds to the local time stamp when crash occurred. When you see a difference between the file modified date and the time stamp in the filename, this can be an indicator that the crash dump was created on a PC set to a different timezone.

Time stamp in Wireshark
Internally Wireshark saves the time stamp of a packet in UTC. By default Wireshark displays a captured packet in "Date and Time of Day", (Ctrl+Alt+1) which corresponds to the adjusted local time. A packet from a capture file shown on a computer in a Berlin timezone to be captured at e.g. 14:33, could be captured at 13:33 local time on a computer in Lisbon. It is important to keep this in mind when discussing an issue with people in a different time zone.

Note that Wireshark also allows displaying the "UTC Date and Time Of Day" (Ctrl+Alt+7). Make sure that you use the correct setting. When two people from different time zones talk about a capture file, this display format may help have an identical view. It also matches the log entries from the diagnosis server nicely.

Time stamp in Windows event log
The time displayed in the Windows event log is local time. The time stored in the native Windows Event Log format (*.evtx) is UTC. Therefore when you view a saved windows event log on another computer in a different timezone, the adjusted local time is displayed.
When you export the Windows Event Log in text format, the exported file contains the local time, and not the UTC time. Information about which timezone is used, is not included.
The timestamps for events from the Windows Application event log shown in the System Information Collector, are in UTC.

Manual time changes
Only users with administrative rights can change the system time in Windows.  It can become quite hard to analyze information from different sources when the system  time is adjusted. There can be appear to be gaps in log files or multiple entries may be shown that don't make any sense.

When the user manually changes the system time, an entry in the Windows Event log is created (System Event Log).

Time in virtual machines
Accurate time keeping inside virtual machines is not straightforward. Normal PCs take their time from the hardware clock once on system startup, and keep their own time based on hardware events.  A virtual machine does not have a true hardware clock, yet the hypervisor will set the RTC on startup. With several virtual machines on one host, the simulated events for multiple Virtual Machines cause the time inside the virtual machine to drift much more than on a normal PC. Excessive load (CPU and Memory Usage) by applications running in the VM can further aggravate this issue and can cause significant time differences compared to the actual time outside the VM.

Leap seconds
UTC is determined based on an atomic clock, while previously time was measured by the rotation of the earth. As the rotation of the earth slows down, leap seconds need to be added to UTC. When this is necessary, it occurs on either June 30th or December 31st of a year at 23:59:59, the clock will then go to 23:59:60, rather than 0:00:00. Since the introduction of leap seconds in 1972, there have been 35 leap seconds added to UTC.

While it is not necessarily important for a general analysis, it is good to know that such a thing exists.

Remote desktop
Consider that when using remote desktop, you are viewing the remote systems local time.

SIC and timestamps
All timestamps shown in the System Information Collector (Eventlog, file modified dates etc.) are in UTC. When the system information is collected, SIC will also contain the information for which timezone the computer is configured that SIC was executed on.

Known time(zone) issues
When an external time stamp is received, it often is defined in milliseconds since 01.01.1970 (unix time). If the received time stamp value is "0" and is considered local time, this can potentially cause issues on computers running in a timezone of UTC+1 .. UTC+12, as one or more hours would need to be subtracted to retrieve the UTC time, and a negative time would be the result.

Unix time stored in a signed 32 bit integer will overflow in 2038 when considered as the number of seconds since 01.01.1970. (also known as the y2k38 problem or unix millennium problem). For computer software system dates that are before 1970 or before 1901, or after 2036 or after 2106 can be problematic and could lead to unexpected results.

Another overflow may present itself when counting milliseconds since system startup and storing this information in a DWORD. After 49 days of continuous operation there will be an overflow. If the software does not correctly check for an overflow, this can cause issues.