Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

XASX open time is incorrect #250

Open
j7zAhU opened this issue Oct 17, 2022 · 14 comments
Open

XASX open time is incorrect #250

j7zAhU opened this issue Oct 17, 2022 · 14 comments
Labels
calendar update Calendar needs updating reference Notes retained for reference

Comments

@j7zAhU
Copy link

j7zAhU commented Oct 17, 2022

Group 1 ASX stocks open at 10am +/- 15 seconds. This means there may be a "left index 9:59" trade time on approximately 50% of trading days.

https://www2.asx.com.au/markets/market-resources/trading-hours-calendar/cash-market-trading-hours

@ValueRaider
Copy link

Wouldn't 9:59:45 be rounded to nearest minute = 10:00? I'm curious where you see 9:59.

@j7zAhU
Copy link
Author

j7zAhU commented Oct 23, 2022

if a trade happens at 09:59:45 then it will be in the minute bar "9:59->10:00", with a left label "9:59"

@maread99 maread99 added the reference Notes retained for reference label Oct 23, 2022
@maread99
Copy link
Collaborator

maread99 commented Oct 23, 2022

Hi @j7zAhU, this is a peculiar one, thanks for raising it.

I can certainly appreciate the argument that the open could be 09:59 because, as you point out, a relatively small selection of stocks can print a trade during the minute from 09:59 - 10:00, or more precisely from 09:59:45 - 10:00:00.

This situation is similar to XTAE (#146), but not the same. XTAE can print a trade any time from 09:59:00, whereas the earliest that a trade can be printed for XASX is 09:59:45, i.e. XASX is never open at 09:59:00 (for regular trading) . Indeed, it's never open before 09:59:45.

I think the question becomes 'does that 15 second window warrant a trading minute of its own, with the open set to 09:59, or as @ValueRaider intimated, should it be rolled into the minute from 10:00 - 10:01'.

One use case of exchange_calendars is to create indices against which to align market data. Although XASX trades can be printed between 09:59:45 and 10:00, I don't know of a data provider that offers 09:59 - 10:00 as a minute of data. Yahoo shows it in the charts (see example at end of comment), but this minute isn't available via the API (at least not as accessed by either yfinance or yahooquery). Changing the open to 09:59 would therefore throw out clients that use exchange_calendars to align market data (I'll put my hand up to a vested interest here - this is what market_prices does).

For the moment at least, I'd favour retaining the open as 10:00 and assuming that trades printed between 09:59:45 to 10.00 are rolled into 10:00 - 10.01. I think there would be more of a case for setting the open to 09:59 if anyone can show there are popular data sources with ' 1 minute' data that includes the 09:59 - 10:00 minute.

Aside on XASX opens

Looking at how the opening times for XASX actually run from 10:00 through 10:09 (+/- 15 seconds) depending on the equity symbol, strictly there should be five subclasses of XASX to cover each equity group.

Aside on trading_seconds

The 09:59:45 open issue really comes from exchange_calendars effectively having a minute resolution. The library provides for interrogating trading sessions and minutes, but not trading seconds.

One solution would be to make the resolution 'seconds' and therefore provide for defining the open time here as 09:59:45. Would need some thought as to how to best implement - might sound simple, but could involve at least the following:

  • for all the methods that provide for interrogating trading minutes, would need to offer analogous methods for interrogating trading seconds.
    • tests for all those new methods.
  • holding 60x as many Timestamp objects in memory (assuming that the current minute implementation is replicated - although there might be a better way to do it).

Example of a print in that 15 second window

Example of 09:59 - 10:00 minute included to yahoo chart (although this minute is not included in the data returned by the yahoo API as accessed via either yfinance or yahooquery). Example for ASX.AX 2022-10-18 09:59 - 10:00.

image

@j7zAhU
Copy link
Author

j7zAhU commented Oct 23, 2022

Hi @maread99

I discovered this issue doing exactly what you mentioned - indexing against a data query. In this case it is the Bloomberg API. The following is some minutely OHLC output for the stock BHP AU Equity

image

The timezone is UTC+10. Notice the large volume in minute 9:59. It is indeed the opening print. You can argue that the two most important timestamps of the day are currently not captured. I think they ought to be included.

I love the library otherwise.

@ValueRaider
Copy link

What happens if you request larger intervals? Does BB merge those 15 seconds into the interval starting on hour?

@j7zAhU
Copy link
Author

j7zAhU commented Oct 24, 2022

15min candles:
image

@maread99
Copy link
Collaborator

Certainly strengthens the argument for a 09.59 open. On the back of this I'd have no objections to a PR changing the open to 09.59.

@j7zAhU, if you're using exchange_calendars to index price data you might be interested in the market_prices library. It handles all the data alignment and provides a host of functionality to query and interrogate the price data. Basically, what the tutorials there show that you can do with data from Yahoo you could do with data from Bloomberg (just need to concrete a subclass of the underlying abstract base).

Also, couple of polite requests...

  • would you mind posting the same 15min data as above but for an XASX equity that opens in one of the later intervals?
  • would you know how Bloomberg handles illiquid equities. For example, if requesting 15min data, what would be the bounds of the interval covered by the first timestamp for an equity that, say, prints its first trade at 10:42 local time?

Cheers

@j7zAhU
Copy link
Author

j7zAhU commented Oct 26, 2022

This is for the stock RIO. start_datetime="2022-09-25 00:07:00", end_datetime="2022-09-27 23:59:59". It returns the same data if I set the start time at 00:00:00 or even 23:59:45

image

@j7zAhU
Copy link
Author

j7zAhU commented Oct 26, 2022

Here is a stock from today. It printed twice
image

The BBG output is below (note that now we are +11 hours) - The index in this dataframe is at 11am local:
image

@maread99
Copy link
Collaborator

Thank you for those @j7zAhU.

This is for the stock RIO. start_datetime="2022-09-25 00:07:00", end_datetime="2022-09-27 23:59:59". It returns the same data if I set the start time at 00:00:00 or even 23:59:45

Any chance of being able to see this same query for RIO at 1min intervals? Thanks!

@maread99 maread99 added the calendar update Calendar needs updating label Oct 26, 2022
@j7zAhU
Copy link
Author

j7zAhU commented Oct 26, 2022

the 25th was a Sunday, but if I use 26th as the start date it looks exactly the same.
image

@maread99
Copy link
Collaborator

The Bloomberg data is certainly not indexed as I would have anticipated. The fact the 15min intervals are anchored on 23:59 even through the first trade doesn't register until 00:06 suggests some knowledge of the underlying exchange, with the exchange assumed to open at 23:59. But in this case, why does the first stamp for the other stock you offered show at 00:00? Not sure what's going on.

In any event, as I mentioned, I wouldn't object to the open being 09:59 - please PR if you want to request the change.

Thanks for all the info @j7zAhU!

@j7zAhU
Copy link
Author

j7zAhU commented Oct 26, 2022

Glad I could help. I prob won't have the time to submit a PR in the foreseeable future. Thanks for taking the feedback on board

@maread99
Copy link
Collaborator

If you do find yourself needing the change, the PR would be pretty simple, workflow at the bottom of this page.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
calendar update Calendar needs updating reference Notes retained for reference
Projects
None yet
Development

No branches or pull requests

3 participants