1
$\begingroup$

I'm interested in the impact of a press release on related stock prices. The reliability of the timestamp is also important to me.

Of course, an important point here is the realtime latency of a platform, i.e. how many (milli)seconds pass from the publication at the source until this message reaches its destination. This is not the main aspect I'm looking for, but rather: How accurate and precise are the timestamps (creation, modification, publication...) that are attached to a news message, e.g. a press release? Imagine using the data in a scientific publication, then the data points used in a graph should have error bars (better: a standard deviation) on the t axis.

Examples:

Can anyone explain to me how this works? E.g.

  • Is there a standardized timestamp format for press releases (at least within an agency)?
  • Are there typical latencies for premium platforms and "normal" brokers (Bloomberg Terminal vs. IBKR/Yahoo Finance)?
  • Is the displayed date usually the creation date or the modified date or does anyone even care?
$\endgroup$
10
  • 4
    $\begingroup$ A lot of people care, so much that it's a huge business - BBG sells so called event driven feeds, as do most competitors. Standard for API solution will be UTC time stamps. I cannot comment on what provider will be fastest because it's not my area of expertise but generally this will cost a lot of money because information advantages are "priceless", although you do not need real time, which should be cheaper. If you have access to Bloomberg, you can ask them on their systems detail. $\endgroup$
    – AKdemy
    Commented Aug 3, 2022 at 17:55
  • 2
    $\begingroup$ You should usually find NIST and UTC is used throughout and they are essentially the same time. NIST is the “US version” of the UTC time standard and they synch to each other. As an end user with a GUI (Reuters or BBG terminal for example) you will see the time of your interface's settings but underneath it will be synced to UTC almost surely. $\endgroup$
    – AKdemy
    Commented Aug 3, 2022 at 18:09
  • 2
    $\begingroup$ The only way to get accurate timestamps without paying is to record them yourself in realtime, this isn't an easy problem to solve. You won't get them from the website itself, yeah it will say "published 7:00pm" but it could have been pushed live several ms before or after 7:00pm. $\endgroup$
    – pyCthon
    Commented Aug 4, 2022 at 16:26
  • 1
    $\begingroup$ I would not trust TradingView. It is very unlikely that the actual source of the news will be slower (your first link is a Reuters article, written by a Reuters journalist and published on Reuters). I know you do not care about real time, but the only way News providers will care about exact time stamps is if they record it accurately themselves. As you figured out yourself, the time stamps of various agencies depends on the time they receive / retrieve it, and store it on their system. $\endgroup$
    – AKdemy
    Commented Aug 4, 2022 at 22:30
  • 1
    $\begingroup$ Bloomberg will not have a latency in your use case. The time stamp is what is recorded on Bloomberg's side - in real time applications, proximity to the server matters, but it will still read the same timestamp, no whether where you are. Unix Epoch is based on UTC under the hood as well, as confirmed by [Tradingviews]tradingview.com/pine-script-docs/en/v4/concepts/Time.html own documentation. Bottom line is that you will need to pay for a service that will be reliable and accurate. None will always be quicker than the other, but Reuters and Bloomberg will be very close to the top $\endgroup$
    – AKdemy
    Commented Aug 4, 2022 at 22:38

1 Answer 1

1
$\begingroup$

A lot of people care:

  • for real time trading purposes
  • for backtesting purposes where a correct point in time is crucial

As an end user with a GUI (Reuters or BBG terminal for example) you will see the time of your interface's settings but under the hood it will be synced to UTC almost surely. For example, Tradingviews Unix Epoch is also based on UTC as well, which is confirmed by Tradingviews documentation. Bottom line, the time will be synced to UTC or NIST, with the latter being the “US version” of the UTC time standard and they synch to each other.

Also regulators base their clocks of UTC. For example, the Markets in Financial Instruments Directive II (MiFID II) in Europe and the Consolidated Audit Trail (CAT) in the USA require server clocks synchronisation to be within 100 microseconds of UTC.

I believe Yahoo and the like store the timestamp when they receive or scrape the news headline. It is not their business to provide fast and reliable news. It is highly unlikely that Tradingview will beat Reuters in a Reuters article, written by a Reuters journalist and published on Reuters.

The only way News providers will care about exact time stamps is if they record it accurately themselves and can earn money with this business model. Data providers like Bloomberg and Reuters created a huge business out of the demand for this. For example, Bloomberg sells so called Even Driven Feeds. You will not need this feed because you do not need real time, but you will need a provider that cares about accuracy.

I recommend you reach out to the major providers and ask what they can offer. To figure out the impact on financial markets also requires you to get accurate market data. Based on your request at least down to the second. That in itself will be quite difficult to obtain, especially if you need a bit of history as well.

To see the accuracy of release data, if you have access to Bloomberg, you can look at ECO, for economic data calendar which shows the time of scheduled releases. You can backdate this and compare with the news articles that come in. When you see BFW as the source - it will be a direct automated report once retrieved, with the time stamp in seconds. ECMI uses these time stamps and computes the reaction of selected securities to surprises.

$\endgroup$

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.