Opening prices redux

This is about the kink in the opening price data that exists at 8/26/2004. First, to make sure everyone knows the state of play: All opening prices that were captured on or before 8/26/2004 are not really opening prices, but rather the closing prices of the same date since the data provider did not capture opening prices until 8/27/2004. The details to all that are captured in the following threads:
https://www.portfolio123.com/mvnforum/viewthread_thread,5377#!#25373
https://www.portfolio123.com/mvnforum/viewthread_thread,5389_offset,0

I have to admit that I was not aware of this. I guess that’s on me since it’s fully disclosed. But, as I recently found out, there’s more to the break between dates up to and including 8/26/2004 and all later dates. To visualize the issue I created a simple screen selecting only JPM stock. Take a look at the screenshot with the as of date 8/28/2004. This date is a Saturday, so the screen sets the “Start Date” to the following Monday, 8/30/2004. The “Start” Price of 24.28 is the adjusted close of 8/30/2004 (there are debates elsewhere on the forum re: why one might choose the close instead of the open price – just know that screens use closing prices). The price open(0), displayed as the variable @lastOpen is the unadjusted point-in-time opening price, also as of 8/27/2004. This makes sense since the index value 0 indicates “most recent” as of the selected date. the variables @nextOpen and @nextOpen_W have the unadjusted opening price of 8/30/2004, 39.67. BTW: open_w() started working in production today. Thanks to the team for making this happen!

So far, so good. All these prices can be confirmed by looking up the respective prices in the “issue” tab of JPM’s snapshot page (see the prices with blue borders in the two screenshots with price CSV exports.

BUT: Then I ran the same screen again, but this time as of 8/21/2004. One week earlier than before, and before the true opening prices were captured. My expectation was that the “Start” price would mean the same thing as before, i.e. adjusted closing price of 8/23/2004 (the Monday following the Saturday as of date). This was confirmed. Next, I expected that @lastOpen (open(0)) would point to the (unadjusted) closing price = opening price of 8/20/2004 (Friday before the Saturday as of date), while @nextOpen (open(-1)) and @nextOpen_W (open_w(-1)) would point to the unadjusted opening price = closing price of 8/23/2004, the Monday following the as of date. But all of that was false. Prior to 8/27/2004, the indexing of the opening prices seems to be off by one day (compare with the non-adjusted prices with a red outline in the screenshot).

Unless I am mistaken, this is an error and a systematic one at that. I.e. not restricted to JPM. In the online screens, this might not be a big deal, but if one uses the additionalData construct in the API (rank_ranks() in the Python API, for example), and happens to d/l opening prices, this is most likely not the desired data. Open(-1) should be the next opening price, not the opening price of the Friday before.




JPM unadj prices.png


JPM adj prices.png


My apologies, at first I mistakenly added the screen as of 8/28/2004 twice, while omitting the screen as of 8/21/2004. I added the latter by editing the post, but I couldn’t see how to delete the extra attachment from the existing post.

oh boy . those are some old posts! We obviously never got around filling in open prices from our raw data feed. It was not as trivial as we first thought and time passed, and the task was buried by others.

In hindsight we should have never filled in open prices in the first place. Just return N/A. Nothing other that the real thing makes great sense.

Something is fishy with open prices . Might have to do with dividends. We’ll investigate. Thanks