I find that storing ZonedDateTime in your database as a UTC epochTime (long or int datatype depending on precision required) handles the use case where you need to store a precise moment in time, and is guaranteed to work across DB implementations.
> Today’s equity market structure is highly fragmented, consisting of fifteen national
securities exchanges, over thirty alternative trading systems, multiple single-dealer
platforms within broker-dealers, and other forms of order matching
While the fragmentation of trading venues has led to competition on fees, in my experience it has actually widened the effective spread (spread + fees) and created a more difficult environment for customers.
Let's say a market-maker would like to trade 100 contracts. Any less than that is great, and any more than that is bad, as the counter-party is likely well informed about their trade. With one exchange, the market-maker can post their 100 contracts on that exchange, and be confident that the most risk they will take on is 100 contracts.
With multiple exchanges, the market-maker now needs to spread their exposure across exchanges (say, 10 contracts each on 15 exchanges), which can leave them (A) overexposed across exchanges, and (B) underexposed on any given exchange.
(A) causes a problem because the market-makers compensate for this risk by widening spreads. If the most sophisticated counterparties in the market can access liquidity across exchanges, the market-maker needs to at least statistically account for that possibility.
(B) causes a problem for customers with less sophisticated market access. In the example above, a customer with access to 1 of 15 exchanges only has the ability to trade 10 contracts, when they could trade 150 contracts with connectivity to all 15 exchanges.
For a real life example of where single listing works, you can currently trade over 20m of notional value with a spread of about .01 basis points in the ES future listed on the CME.