get-bars changes limit behavior compared to get_barset

[ankurgoel77]

The original README claims that limit is calculated from the end date. This was true with get_barset, but for get_bars, limit is calculated from start instead. I have corrected the README to reflect this.

For example, the following command will get 5 quotes starting from Oct 4, instead of the last 5 quotes ending Oct 20:

api.get_bars("AAPL", TimeFrame.Day, start="2021-10-04", end="2022-10-20", limit=5, adjustment='raw')

[gnvk]

If the end date is not specified, "now" is used.

This isn't completely true: for users with a free plan, actually "now - 15 minutes" is the default end.

[akarun2405]

Why is there even a behavior change for get_bars vs get_barset.

One more annoyance is that get_barset worked when not providing any start or end or limit. However get_bars requires us to enter a start_date. I should logically be able to supply for example, a limit=300 to get_bars and get the last 300 bars for the time-frame requested.

[gnvk]

Why is there even a behavior change for get_bars vs get_barset.

There are technical reasons why get_bars doesn't support ordering by descending timestamps, only by ascending.

One more annoyance is that get_barset worked when not providing any start or end or limit. However get_bars requires us to enter a start_date.

This isn't true: start is an optional parameter in get_bars, too. If you don't provide it, it will default to the beginning of the current day. end also has a default (the latest timestamp you are allowed to query based on your subscription) and limit too: no limit, meaning you will get all the bars in the specified start-end interval.

I should logically be able to supply for example, a limit=300 to get_bars and get the last 300 bars for the time-frame requested.

Again, "the last N bars" is not something the v2 API provides. By the way, my personal opinion is that in most scenarios it doesn't make sense anyway: if you ask for the last 300 AAPL bars, you'll most likely get the bars for the same day, but if you do the same for a rarely traded symbol, you can end up with bars days, weeks or even months old. But this argument is subjective, the real answer here too is that this is not supported at this time for technical reasons.

[akarun2405]

This isn't true: start is an optional parameter in get_bars, too. If you don't provide it, it will default to the beginning of the current day. end also has a default (the latest timestamp you are allowed to query based on your subscription) and limit too: no limit, meaning you will get all the bars in the specified start-end interval.

Having a fixed default of start=beginning of current day is not very app friendly. Explains why I didn't see any bars when querying for daily chart and not supply start and end.

Again, "the last N bars" is not something the v2 API provides. By the way, my personal opinion is that in most scenarios it doesn't make sense anyway: if you ask for the last 300 AAPL bars, you'll most likely get the bars for the same day, but if you do the same for a rarely traded symbol, you can end up with bars days, weeks or even months old. But this argument is subjective, the real answer here too is that this is not supported at this time for technical reasons.

I think you are confusing last 300 trades vs bars.. when you request 300 bars for a stock at a given time-frame, the start date is going to be the same no matter the volatility of the stock. The number of bars is a function of time rather than volatility.

@gnvk would you know if this limitation of V2 not supporting descending timestamps, thus limit from an end date, will be bridged in the future? If not, can we continue to use V1 version? Do we run a risk of V1 getting deprecated soon?

[gnvk]

Having a fixed default of start=beginning of current day is not very app friendly. Explains why I didn't see any bars when querying for daily chart and not supply start and end.

Originally there was no default for the start parameter, which I think was optimal. But many of our users complained about it, so that's why it has a default now. I agree it's not perfect, but I can't really think of a better one. Can you?

I think you are confusing last 300 trades vs bars.. when you request 300 bars for a stock at a given time-frame, the start date is going to be the same no matter the volatility of the stock. The number of bars is a function of time rather than volatility.

No, we do not have bars for minutes where no trade happened. And this confusion is exactly my point: you really want the (maximum of) 300 bars in the last 5 hours, which is precisely what the v2 API encourages. You should query for all the bars in the last 5 hours: start = now - 5 hours, end = now (the default).

Would you know if this limitation of V2 not supporting descending timestamps, thus limit from an end date, will be bridged in the future?

I would say it is very unlikely but not completely impossible.

If not, can we continue to use V1 version? Do we run a risk of V1 getting deprecated soon?

Absolutely not. V1 is already deprecated and will be removed soon. You have to understand that it's a huge burden to maintain two completely separate versions and we have already been doing it for many-many months now.

[akarun2405]

I see.. I was under the impression that I would get bars for intervals without trades, just with o,h,l,c pointing to the previous close value. Now this is interesting in that it creates weird pockets if I were to plot this data as is from alpaca.

[sonarcloud]

Kudos, SonarCloud Quality Gate passed!   

0 Bugs
0 Vulnerabilities
0 Security Hotspots
0 Code Smells

No Coverage information
No Duplication information