product_historic_rates not working correct anymore?

[Menox10]

When working with the gdax module it is working as expected but not with cbpro. As example my test code to test 1 hour historical data.

!/usr/bin/python

import gdax import cbpro import time import sys import datetime

public_client = cbpro.PublicClient()

public_client = gdax.PublicClient()

v = public_client.get_product_historic_rates('ETC-BTC', granularity=3600) for items in v: print(datetime.datetime.fromtimestamp(items[0]).strftime('%Y-%m-%d %H:%M:%S'), items[1], items[2], items[3], items[4], items[5])

[uclatommy]

Hey @Menox10, this was fixed by #314, which was just merged to master, but not in the release. If you pip install from the lastest master, it should resolve your issue.

[Menox10]

He @uclatommy, this works indeed when I do a git clone of the code. I have also tested with begin and end for the day charts. Strange is that I can not get data before 8-8-2018??. This is the same for gdax and cbpro. I expect 200 days of data but it failed to run. Any ideas?

#!/usr/bin/python
import cbpro
import datetime

public_client = cbpro.PublicClient()

now = datetime.datetime.now()
end = now - datetime.timedelta(days=14)
start = end - datetime.timedelta(days=100)

v = public_client.get_product_historic_rates('ETC-BTC', start, end,  granularity=86400)
for items in v:
  print(datetime.datetime.fromtimestamp(items[0]).strftime('%Y-%m-%d %H:%M:%S'), items[1], items[2], items[3], items[4], int(items[5]))

[danpaquin]

We have run into an issue with the export of these data from Coinbase Pro since before GDAX, so I do not expect them to resolve this issue in the short term.

There is, however; a bug with the current pip release that causes this endpoint to break the code. I will leave this open until we update the pip license, but after we have some CI setup to prevent this from happening in the future.

Thanks for the report @Menox10 !

[uclatommy]

@Menox10, I get my data at 1-minute granularity and have gone as far back as 75 days at that granularity level. I can’t spot anything wrong with your code except that I believe the coinbase pro api expects datetime in utc format so you want: datetime.datetime.utcnow() instead of just now(). The other thing I can think of is that ETC was only recently added as a trading currency to coinbase so maybe they actually don’t have that data. Try querying for a different currency pair and see if it works.

On Aug 25, 2018, at 8:36 PM, Menox10 notifications@github.com wrote:

He @uclatommy, this works indeed when I do a git clone of the code. I have also tested with begin and end for the day charts. Strange is that I can not get data before 8-8-2018??. This is the same for gdax and cbpro. I expect 200 days of data but it failed to run. Any ideas?

!/usr/bin/python

import cbpro import datetime

public_client = cbpro.PublicClient()

now = datetime.datetime.now() end = now - datetime.timedelta(days=14) start = end - datetime.timedelta(days=100)

v = public_client.get_product_historic_rates('ETC-BTC', start, end, granularity=86400) for items in v: print(datetime.datetime.fromtimestamp(items[0]).strftime('%Y-%m-%d %H:%M:%S'), items[1], items[2], items[3], items[4], int(items[5])) — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub, or mute the thread.

[Menox10]

@uclatommy and @danpaquin The problem was indeed that I used ETC which was added recently (8/8/2018) to gdax (gbpro). When I select "BTC-EUR" I could download 300 days and I could even do this for a year ago. So the API is correct with at least 200 days. So you can remove the gdax api issue for this. The utcnow() is not needed but also works. Thanks for your help both !!

('2016-11-05 01:00:00', 625.01, 639, 637.29, 635.47, 217)
('2016-11-04 01:00:00', 616.34, 642.25, 620.1, 637.02, 361)
('2016-11-03 01:00:00', 610, 675, 671, 620.9, 859)
('2016-11-02 01:00:00', 655, 671, 661.58, 671, 407)
('2016-11-01 01:00:00', 639.33, 673.25, 639.41, 661.58, 488)
('2016-10-31 01:00:00', 625, 649.74, 634.08, 639.42, 369)

[danpaquin]

Thanks for resolving this @uclatommy!

This is another area for improvement to throw a value error if the time is not in UTC format for a better developer experience.

[mcardillo55]

@danpaquin that would be nice but I'm struggling to think of a feasible way to do it.

There is no timezone data included in datetime.now() vs datetime.utcnow(). We could add a new package to manage timezones, but then we're requiring devs to include tz data in their calls which seems even more complex.

Did you have a different idea in mind?