[This message was posted by David Rosenborg of Pantor Engineering AB <[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/1ad53f98 - PLEASE DO NOT REPLY BY MAIL.]
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: > 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 -~----------~----~----~----~------~----~------~--~---
