[Martin Mayer <martin.mayer@xxxxxxxxxxxxxxxxxx>]

Hello Guy,

thank you very much for your answer.

> It's possible in that you can subtract two time_t values.
>
> However, what you get is *not* guaranteed to give the number of SI seconds that have elapsed between the two instants in time.
>
> A time scale of "SI seconds that have elapsed since some epoch" *does* guarantee (modulo clock error) that a difference between time stamps will give the number of SI seconds that have elapsed between the two instants (by definition).

Totally right. That's exactly my point.

> Presumably you mean "UNIX time 1483228800".

Yes, you are right - the converter I used took my time zone into account and I didn’t notice it - shame on me.
(I spent so much time trying to be understandable for everyone and also precise, and then, this happens. Annoying *argh* )

> So part of the goal here is to be able to display those TAI and UT1 times?

TAI yes, for UT1: Display, yes. Math with other time scales, I guess not. As UT1 has lots of measurements, calculations from/into other time scales will be an issue. I think we have to stay with displaying UT1 times with UT1 time scale indication/suffix (the user has to know that the displayed time is UT1) but base all math on UTC.
Otherwise, we'd need to implement or somehow access the IERS database. I don't know if this is or can be a goal.
Whats is your opinion (see also option 2 below)?

> My choice would be "count of SI seconds since 1970-01-01 00:00:00 UTC, plus nanoseconds", as *there's already code and data that can display that as UTC*.

This is totally fine. It just defines what our internal *Time-Zero* is.
So, the only change to now would be:
- Don’t count UNIX seconds, count SI seconds instead.

This additionally needs the following work for the GUI:
- Make a 61st seconds displayable if applicable
- Take leap second data into account when displaying UTC
- Display the corresponding time scale suffix instead of 'Z'
- Adjust dfilter to handle time scales

The MR already includes some of it but is *not* based on *Si-seconds elapsed since*.

> If we're going to use nstime_t for times with different flavors of seconds, e.g. for SI-second-based time (TAI, UTC), POSIX time, UT1, possibly others, we'd have to have the nstime_t include a designation of which flavor of second is being used.

I think this is not needed. If we define the nstime_t as *SI-seconds since 1970* for instance, timestamps must be saved as this. This means, a packet's timestamp data (e.g. NTP timestamp) must be converted to and stored in *Wireshark time scale*.
` ABSOLUTE_TIME_*` would be responsible to convert and show the time back in the appropriate time scale.
If (and that is important to decide) we treat UT1 (and maybe other time scales where its second's length is *not* constant) as UTC - we don’t need different flavors of a second. All seconds are SI-seconds. If we need to treat UT1 right, well, we'll have a task to do :)

Option 2: Don't use a *Wireshark time scale* and handle each time scale with its own definition of a) starting point and b) second length/definition. Then we need nstime_t to store the type.
Calculations like *DateTimeA_UTC - DateTimeB_UT1* won't be easily possible. But we may stay closer to the scale's definition/precision - even exactly.

Conclusion:
- Do we need to define the Wireshark time scale (starts at 1970-01-01 00:00:00 UTC?) as new internal basis?
- Do we need to be able to do calculations with timestamps of different time scales
- Do we support the SI-second only or do we allow each nstime_t to be distinctively *typed* in a scale

Off-topic: Because you mentioned capture timestamps:
draft-ietf-opsawg-pcapng is ambiguous for *if_tsresol*. This defines the precision of *seconds since 1970*. Presumably, this relates to *UNIX timestamp seconds*, but the wording is not precise.

Martin