4 ms·

> You can just smear a second by speeding up a clocks temporarily. And it will counteract the drift between UTC and TAI. No, you cannot "just" do this in many

> You can just smear a second by speeding up a clocks temporarily. And it will counteract the drift between UTC and TAI. No, you cannot "just" do this in many instances. Some folks (especially in regulated industries) need to have a close link to UTC, and so purposefully smearing things would be non-compliant.

nine_k 3y ago
Can you provide an example? From my experience, stuff that needs serious synchronization does not care much about absolute time, and optimizes for very low relative offsets. Other stuff is OK with half-second or so in offset, and can tolerate much more.
- gpderetta 3y ago
  MIFID II requires [1] at most 100us divergence from UTC for timestamps for reportable events. [1] https://ec.europa.eu/finance/securities/docs/isd/mifid/rts/160607-rts-25-annex_en.pdf https://ec.europa.eu/finance/securities/docs/isd/mifid/rts/1...
  - ggm 3y ago
    Which begs the question, was the Google smear inside that limit? Answer; During the smear, clocks run slightly slower than usual. Each second of time in the smeared timescale is about 11.6 μs longer than an SI second as realized in Terrestrial Time.
    - toast0 3y ago
      By design, the Google smear peaks at about 500ms off When :60 starts, Google smear is at 59.500, and when :0 starts, it's at :0.500. IIRC, there were some different strategies on how to modulate the length of the seconds. One method was to make all seconds in the 24 hours around the change uniformly longer; another was to increase second length slowly and then decrease slowly after the leap second. Either way, you'd need to do some math to determine when you were out of compliance, and if that overlapped with time you were operating where compliance was needed. IMHO, better to not smear, and just not trade for a couple seconds around the leap second.
      - ggm 3y ago
        You're basically trading your risk for everyone else's. Not that trade effects and compliance aren't a problem, but the point is you're discounting the impact of the -1 second effect on everything else. I don't usually "stand with google" on things, but I think this time I stand with google: better to smear, than invoke negative time and time repeats. If need be declare a trading holiday. Or, ensure the smear is within the compliance limits.
        toast0 3y ago
        > Or, ensure the smear is within the compliance limits. I don't see how you can be within 11.6 μs of UTC and also smear. If UTC requires leap seconds in both directions (as it does) and your time keeping must be very close to UTC, you must keep leap seconds (this isn't too hard, historically FreeBSD has done just fine, although Linux has crashed a few times, and MySQL didn't like it at least once even if your OS was fine; other applications also had issues). And you've got to figure out how to log :60, rather than :59 twice; this is probably harder. Personally, I'd vote for all seconds be the same length, and all days the same number of seconds, and all days the same number of hours. Maybe ocassionally redefine time zones, until the seconds per day is really off. But you know, the powers that be insist that UTC stay close to UT1, and DST is a thing too (different orgs, but still messed up)
  - reisse 3y ago
    Somewhat off-topic question: has anyone ever been seriously punished for violating MiFID requirements? Has anyone ever tried to ask a market participant for five years old trading data and verify it is synchronized with UTC? I've yet to see anyone who seriously tried to be compliant both to the spirit and to the letter of MiFID. It's both hard and expensive to the point where the fine expectancy might be lower than implementing costs. Everyone do just enough to plausably deny they're not compliant.
    - gpderetta 3y ago
      At $PREVIOUS_JOB non-compliance was really not an option. Just in my team, for two years, we had at least two people at any time working on MIFID-II compliance upgrades. We had multiple levels of recording, the last resort was really storing raw pcaps of trading recording. Very expensive.

nine_k 3y ago

Can you provide an example? From my experience, stuff that needs serious synchronization does not care much about absolute time, and optimizes for very low relative offsets. Other stuff is OK with half-second or so in offset, and can tolerate much more.

gpderetta 3y ago
MIFID II requires [1] at most 100us divergence from UTC for timestamps for reportable events. [1] https://ec.europa.eu/finance/securities/docs/isd/mifid/rts/160607-rts-25-annex_en.pdf https://ec.europa.eu/finance/securities/docs/isd/mifid/rts/1...
- ggm 3y ago
  Which begs the question, was the Google smear inside that limit? Answer; During the smear, clocks run slightly slower than usual. Each second of time in the smeared timescale is about 11.6 μs longer than an SI second as realized in Terrestrial Time.
  - toast0 3y ago
    By design, the Google smear peaks at about 500ms off When :60 starts, Google smear is at 59.500, and when :0 starts, it's at :0.500. IIRC, there were some different strategies on how to modulate the length of the seconds. One method was to make all seconds in the 24 hours around the change uniformly longer; another was to increase second length slowly and then decrease slowly after the leap second. Either way, you'd need to do some math to determine when you were out of compliance, and if that overlapped with time you were operating where compliance was needed. IMHO, better to not smear, and just not trade for a couple seconds around the leap second.
    - ggm 3y ago
      You're basically trading your risk for everyone else's. Not that trade effects and compliance aren't a problem, but the point is you're discounting the impact of the -1 second effect on everything else. I don't usually "stand with google" on things, but I think this time I stand with google: better to smear, than invoke negative time and time repeats. If need be declare a trading holiday. Or, ensure the smear is within the compliance limits.
      - toast0 3y ago
        > Or, ensure the smear is within the compliance limits. I don't see how you can be within 11.6 μs of UTC and also smear. If UTC requires leap seconds in both directions (as it does) and your time keeping must be very close to UTC, you must keep leap seconds (this isn't too hard, historically FreeBSD has done just fine, although Linux has crashed a few times, and MySQL didn't like it at least once even if your OS was fine; other applications also had issues). And you've got to figure out how to log :60, rather than :59 twice; this is probably harder. Personally, I'd vote for all seconds be the same length, and all days the same number of seconds, and all days the same number of hours. Maybe ocassionally redefine time zones, until the seconds per day is really off. But you know, the powers that be insist that UTC stay close to UT1, and DST is a thing too (different orgs, but still messed up)
- reisse 3y ago
  Somewhat off-topic question: has anyone ever been seriously punished for violating MiFID requirements? Has anyone ever tried to ask a market participant for five years old trading data and verify it is synchronized with UTC? I've yet to see anyone who seriously tried to be compliant both to the spirit and to the letter of MiFID. It's both hard and expensive to the point where the fine expectancy might be lower than implementing costs. Everyone do just enough to plausably deny they're not compliant.
  - gpderetta 3y ago
    At $PREVIOUS_JOB non-compliance was really not an option. Just in my team, for two years, we had at least two people at any time working on MIFID-II compliance upgrades. We had multiple levels of recording, the last resort was really storing raw pcaps of trading recording. Very expensive.