[Martin Mayer <martin.mayer@xxxxxxxxxxxxxxxxxx>]

Hi all,

I'm writing here to move the discussion from my MR (!25913) away from GitLab.

I want to show what my intentions are, what limitations we currently have and what solutions we could possibly implement.

Please note that I'm trying to explain my thoughts without rating the effort it may take to realize the necessities nor how it could be implemented programmatically. It is a very theoretical topic which may cause substantial changes. But it is important to talk about.

Hopefully, I'm not missing a thing...

## Time scale basics

We already discussed most of it in the MR, but I just want to repeat the most important of it.
Time scales are the basis for time measurement. A certain scale is defined by its starting point and its scalar value which constantly increases.

We are used to thinking and living in seconds, hours, days, etc., which is fine because the second is the most important unit for time scales, the SI-second to be exact.

Let's start with the most important time scale which is the basis for our ticking clocks - the International Atomic Time (TAI). Distributed atomic clocks around the world are used to measure the SI-second. This scale only cares about the second. It does not care about day and night, the earth rotation or something else.

What brings us to the next: Universal Time 1 (UT1). This scale is aligned with astronomical observation, which means midnight must be aligned with astronomical midnight. Because the earth rotation is slowing down, in average over the past decades, an UT1 second's duration is a) longer than a SI-second and b) not constant.

An important one I want to describe is UTC. The Coordinated Universal Time which we are all used to. It combines the SI-second with astronomical observations - and this is the inherent problem because astronomical midnight is bound to the earth rotation. The UTC second's duration is the same as the SI-second's duration which leads to the fact that, over time, midnight gets coming earlier (it could also come later when earth is accelerating). To overcome this issue, UTC is aligned with astronomical observations from time to time. This happens when the difference between UT1 and UTC (called DUT1) reaches the bounds of -0.9 < DUT1 < +0.9 seconds. This is when leap seconds are added or removed to UTC.

## Time scale arithmetic

Wireshark's internal time scale is UNIX time. This time scale counts the seconds since `1970-01-01 00:00:00 UTC` which is not totally exact. The downside is that UNIX time cannot handle leap seconds. A UNIX day strictly has 86400 seconds. When leap seconds are added or deleted, UNIX time simply pauses, repeats or jumps (there are different approaches).
The result of this behavior is that time arithmetic is not possible because precision is lost.

Example:

UNIX time `1483225200` equals `2017-01-01 00:00:00 UTC`

If one unit is subtracted from UNIX time (`1483225199`) it equals `2016-12-31 23:59:59`.

This is incorrect because moving back one second in UNIX time means moving back two seconds in reality. A leap-second was added to UTC (`2016-12-31 23:59:60`) which is not representable in UNIX time.

## Calendar and user date representation

A calendar is one way to represent a certain coordinate at a time scale in an alternative format. We are all used to the Gregorian calendar which follows our personal astronomical observations and divides years into months, and months into days, and so on. It follows a proleptic scheme but has in fact nothing to do with the time scale. Gregorian dates can be applied to any time scale.

Why do I note that? Because it is important for our date and time representation in Wireshark.

If we introduce multiple time scales, we must indicate it when displaying a time. That means for example, `2026-07-26 23:59:50 UTC` is the exact same point in time as `2027-07-27 00:00:27 TAI`.

The display value is different because we express the same time in different time scales.

This is also important for display filters.

## Which protocols make use of it

Currently, I'm focusing on NTPv5 which introduces TAI and UT1 as new time scales. But PTP is also affected. PTP (depending on version) can transport timestamps in UTC, arbitrary or UTC-relative timescales (which could be TAI, identified by offsetUtc).

It may also affect dissectors for GNSS, because each, GPS, Galileo and BeiDou, have their own time scale.

## Possible solutions

### Pragmatic way

The easiest solution to implement additional time scales is to stay with the internal storage of time as UNIX timestamps. With having leap second information available, we can convert one time scale into another. What we cannot do is calculate exact differences or display UTC dates where leap-seconds were added.

### Correct way

The correct way in my opinion is to implement a new basis time scale for storing timestamps which is continuous and based on SI-seconds. It can even be TAI.

With this, we can implement correct arithmetic without losing precision and give the ability to programmers to show exact times in exact time scales.

### Both

Both approaches require adjustment of display filters because for time strings (e.g. ISO 8601) it's absolutely relevant to which time scale the filter string is applied. With the latter, the representation must also be able to handle 61 seconds in one minute (e.g. `2016-12-31 23:59:60`).


(Thanks to Martin Langer (PTB) for his valuable notes)

Regards,
Martin