[This message was posted by Daniel May of SpryWare, LLC <[EMAIL PROTECTED]> to
the "FAST Protocol" discussion forum at http://fixprotocol.org/discuss/46. You
can reply to it on-line at http://fixprotocol.org/discuss/read/c10430d5 -
PLEASE DO NOT REPLY BY MAIL.]
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:
http://en.wikipedia.org/wiki/Unix_time
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
[You can unsubscribe from this discussion group by sending a message to
mailto:[EMAIL PROTECTED]
--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups
"Financial Information eXchange" group.
To post to this group, send email to [email protected]
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at
http://groups.google.com/group/FIX-Protocol?hl=en
-~----------~----~----~----~------~----~------~--~---
