Imported from previous forum
There is an upcoming leap second insertion event happening on June 30, 2015 (tuesday) and it appears that the official recommended UTC timestamp format to represent this is “19981231-23:59:60” or “19981231-23:59:60.000” since this is in-between “19981231-23:59:59” and “19990101-00:00:00”. Is it safe to assume that all messages sent to/from counterparties at that particular second should have the sending time (tag 52) as the sixtieth second and all match events or market events that take place at that particular second should have transaction time (tag 60) as the sixtieth second?
Just as an FYI, the last leap second insertion event that took place on a trading day was in 1997 and all others since then till 2012 have been on holidays.
Here is the link to the official IERS bulletin: https://hpiers.obspm.fr/iers/bul/bulc/bulletinc.dat
How do you expect this to work in practice? Should system clocks change their usual behaviour when providing timestamps to applications? Or will it depend on the frequency of sync points with a time service such as NTP when exactly a system clock will be set back for one second? The change happens according to UTC and hence is equivalent to many different local times and rarely at midnight local time.
It sounds more like a technical topic than one of semantics. Applications need to be prepared to change their calculation of a timestamp if it is represented as a number of units (e.g. seconds) since a reference point (e.g. epoch). I would expect software libraries to be adapted by mid-2015 to provide the correct timestamp for display. It is thus not just an issue for events occurring at the very moment that the extra second is added.
The FIX semantics are clear about the expected behavior. So are the W3C standards for XML Schema. FIXML messages with HH:59:60 should parse.
Of course whether trading applications and related systems like databases can gracefully handle this are another matter.
Additionally, there’s the question of whether computer clocks will report times that are one second fast after the leap second and will suddenly find that they need to slow down when they next sync with NTP.
Okay I thought that for things like epoch it would mean that the extra second would just be added to the number of seconds since 1970. How this is handled will probably be driven by how the operating system on the server handles the leap second insertion, for example unix implementation of UTC does not support 23:59:60. I am just using midnight UTC as an example but yes this change would happen in local time zones all over with their UTC offsets for example UTC + 3 Hours etc. I guess the semantics are clear but the technology may not support the semantics.