Imported from previous forum
All,
following up on today’s confcall;
AFAICT Dan’s original proposal doesn’t handle leap seconds either. I need to think some more about the significance of leap seconds for FAST.
If anyone has thoughts to share please post.
Best,
Rolf
Isn’t the issue of leap seconds one of synchronization? After all leap seconds means that the clock of the encoder is at a time before or after the clock of (zero or more) decoders right?
If instead of saying that the reference time is Monday midnight, the encoder sends an initial reference date/timestamp stating he is on Wednesday, December 03rd 12am I can compare that against my decoding time (lets say I am on Tuesday, December 2nd 11pm) and I automatically know that they are 1 hour ahead of me. Then all I have to do is do the epoch of the encoder -1hour and I have the actual timestamp on my side.
That way we establish a way of evading the leap seconds problem and also clock synchronization.
What do you think?
All,
following up on today’s confcall;
AFAICT Dan’s original proposal doesn’t handle leap seconds either. I
need to think some more about the significance of leap seconds for FAST.If anyone has thoughts to share please post.
Best, Rolf
Disregard my leap second concern, as it seems most modern day unix clock implementations do adjust for leap seconds.
thanks,
Brian
The more I think about this the more I see there is a chance for inaccuracies by using the a relative timestamp rather than an absolute timestamp. By using a relative time stamp, such as milliseconds since an epoch, you are leaving yourself open to time skew unless you know the specific algorithm that the sender used to calculate the timestamp. I think to reliably use a relative timestamp both parties need to know how the timestamp was calculated to properly interpret it.
This wiki explains the details of an accurately calculated Unix time stamp, including leap seconds.
Since some users may simply rely on the host operating system to generate this number for them, it is important to know the details of the implementation.
You can find a schedule of leap seconds here Leap second - Wikipedia
In the FAST 1.2 extension proposal, we should include the option of absolute timestamps also. The has the added benefit of support implementations like CME FAST who already are using absolute timestamps by simple converting HH:MM:SS.sss into a UInt32 of HHMMSSsss digits.
/Daniel
All,
following up on today’s confcall;
AFAICT Dan’s original proposal doesn’t handle leap seconds either.
I need to think some more about the significance of leap seconds
for FAST.If anyone has thoughts to share please post.
Best, Rolf
Disregard my leap second concern, as it seems most modern day unix clock
implementations do adjust for leap seconds. thanks, Brian
Daniel,
I do not understand the difference between relative and absolute timestamps as described by you. My understanding was that HH:MM:SS.sss and msec since X are equivalent representations of an absolute timestamp, the latter simply requiring less bytes on the wire than the former. I would hope that the representation does not imply a specific calculation algorithm.
Thanks,
Hanno.
The more I think about this the more I see there is a chance for
inaccuracies by using the a relative timestamp rather than an absolute
timestamp. By using a relative time stamp, such as milliseconds since an
epoch, you are leaving yourself open to time skew unless you know the
specific algorithm that the sender used to calculate the timestamp. I
think to reliably use a relative timestamp both parties need to know how
the timestamp was calculated to properly interpret it.This wiki explains the details of an accurately calculated Unix time
stamp, including leap seconds. Unix time - Wikipedia
Since some users may simply rely on the host operating system to
generate this number for them, it is important to know the details of
the implementation.You can find a schedule of leap seconds here
Leap second - WikipediaIn the FAST 1.2 extension proposal, we should include the option of
absolute timestamps also. The has the added benefit of support
implementations like CME FAST who already are using absolute timestamps
by simple converting HH:MM:SS.sss into a UInt32 of HHMMSSsss digits./Daniel
All,
following up on today’s confcall;
AFAICT Dan’s original proposal doesn’t handle leap seconds either.
I need to think some more about the significance of leap seconds
for FAST.If anyone has thoughts to share please post.
Best, Rolf
Disregard my leap second concern, as it seems most modern day unix
clock implementations do adjust for leap seconds. thanks, Brian
I propose that we keep it simple and add a “UNIX time”-style definition of the semantics of the timestamps. That is, no leap seconds.
If you really need leap second disambiguation you can use the combination
(Using copy and delta respectively for these two would render a fairly compact representation)
/David
The more I think about this the more I see there is a chance for
inaccuracies by using the a relative timestamp rather than an absolute
timestamp. By using a relative time stamp, such as milliseconds since an
epoch, you are leaving yourself open to time skew unless you know the
specific algorithm that the sender used to calculate the timestamp. I
think to reliably use a relative timestamp both parties need to know how
the timestamp was calculated to properly interpret it.This wiki explains the details of an accurately calculated Unix time
stamp, including leap seconds. Unix time - Wikipedia
Since some users may simply rely on the host operating system to
generate this number for them, it is important to know the details of
the implementation.You can find a schedule of leap seconds here
Leap second - WikipediaIn the FAST 1.2 extension proposal, we should include the option of
absolute timestamps also. The has the added benefit of support
implementations like CME FAST who already are using absolute timestamps
by simple converting HH:MM:SS.sss into a UInt32 of HHMMSSsss digits./Daniel
All,
following up on today’s confcall;
AFAICT Dan’s original proposal doesn’t handle leap seconds either.
I need to think some more about the significance of leap seconds
for FAST.If anyone has thoughts to share please post.
Best, Rolf
Disregard my leap second concern, as it seems most modern day unix
clock implementations do adjust for leap seconds. thanks, Brian
Hanno, David,
My thinking was that an epoch style time stamp, such as the Unix style, was calculated by the originator using a algorithm that counted the number of seconds between the epoch and now. In a non leap second aware system, the algorithm would be (dayssince epoch * 86400) + seconds since midnight. With a system aware of leap seconds, the seconds per day would be either 86,400 or 86,401 of leap days.
My interpretation may have been incorrect. I was under the assumption that every day with a leap second between now and the epoch would add an additional second to the timestamp, summing 86,401 rather than 86,400 seconds per day on leap second days. Is this not the case ? If 86,400 is always used, and the only risk is the time right at midnight on the day of the leap second, then David’s solution is fine.
Again, see this for a full explanation:
Hanno,
In regards to relative vs. absolute timestamps, I consider all epoch based timestamps relative, as the time is relative to the starting point (the epoch). An absolute timestamp is one that is fixed in time, such as an HH:MM:SS.sss, it explicitly defines a point in absolute time.
/Daniel
Dan -
If we use a UNIX-time-style definition, the only thing that happens is that you cannot distinguish between the leap second and the second after. This is per definition and is not system dependent.
For example, if you have a leap second aware clock on the sending side and want to encode 20081231-23:59:60.123 as a proposed FAST timestamp, you’ll put 1230768000123 on the wire, which at the receiving end translates to 20090101 00:00:00.123, always.
If the same sender sends another message at 20090101 00:00:00.123, the FAST timestamp would again be 1230768000123 and the interpretation at the receiver would be correct this time.
Whether this deficiency matters depends on your application. If it matters (my guess it that it doesn’t in the most cases), the two-field approach is one possible solution.
/David
Hanno, David, My thinking was that an epoch style time stamp, such as
the Unix style, was calculated by the originator using a algorithm that
counted the number of seconds between the epoch and now. In a non leap
second aware system, the algorithm would be (dayssince epoch * 86400) +
seconds since midnight. With a system aware of leap seconds, the seconds
per day would be either 86,400 or 86,401 of leap days.My interpretation may have been incorrect. I was under the assumption
that every day with a leap second between now and the epoch would add an
additional second to the timestamp, summing 86,401 rather than 86,400
seconds per day on leap second days. Is this not the case ? If 86,400 is
always used, and the only risk is the time right at midnight on the day
of the leap second, then David’s solution is fine.Again, see this for a full explanation:
Unix time - WikipediaHanno, In regards to relative vs. absolute timestamps, I consider all
epoch based timestamps relative, as the time is relative to the starting
point (the epoch). An absolute timestamp is one that is fixed in time,
such as an HH:MM:SS.sss, it explicitly defines a point in absolute time./Daniel