Leo4815162342 / dukascopy-node

✨ Download historical price tick data for Crypto, Stocks, ETFs, CFDs, Forex via CLI and Node.js ✨
https://dukascopy-node.app
MIT License
350 stars 66 forks source link

Really Need the Second Data OHLCV #95

Closed awakanto closed 1 year ago

awakanto commented 1 year ago

This was asked before and marked as resolved. Yet, I still cannot download the second data as provided for in the DukasCopy Website. Would you be kind enough to add support for this or to give code pointers on how to achieve this by changing the code?

Thank you.

Leo4815162342 commented 1 year ago

hi @awakanto - we're working on adding second-based timeframes - will keep you updated on the release

awakanto commented 1 year ago

ok thanks

Leo4815162342 commented 1 year ago

@awakanto the new 1-second timeframe (s1) has been added, please try updating dukascopy-node to 1.27.0. And let me know if you need s5, s15, s30

awakanto commented 1 year ago

Hi Leonid, thanks a mil' for this update. I did try to fix it myself before you released this update and got the code working. However I did not fork it because javascript is not my first (or second) language. Looking at your implementation of this, it is neat, easy to read and concise. Mine had almost 50 lines of code :-(

There are a few things, that if possible for you to update on the next version, I would use this latest version. I changed them on the last version that you released so that I could use it.

  1. Changing the headers of the csv OHCL's to match that from Dukas copy. The reason for this is compatibility with the in-house trading bots. I changed this by simply renaming: // src/output-formatter/index.ts var headers = ["Local time", "Open", "High", "Low", "Close", "Volume"]; I find that it is better if the downloader retains the same format as that of the DukasCopy website - it is, after all, a DukasCopy Downloader.
  2. Instead of displaying the "timestamp" field in Unix time, I changed it to match the DukasCopy format. The reason for that again is compatibility. I changed the code to below: if (format2 === "csv" / csv /) { const csvHeaders = bodyHeaders.filter((_, i) => processedData[0][i] !== void 0); const temp_changed_date = processedData.map(([first_element, ...rest], i) => {

    var temp_date = new Date(first_element);

    return [(temp_date.getDate() < 10 ? '0' + temp_date.getDate() : temp_date.getDate()) + '.' + ((temp_date.getMonth()+1) < 10 ? '0' + (temp_date.getMonth()+1) : (temp_date.getMonth()+1)) + '.' +

    temp_date.getFullYear() + ' ' +

    (temp_date.getHours() < 10 ? '0' + temp_date.getHours() : temp_date.getHours()) + ':' + (temp_date.getMinutes() < 10 ? '0' + temp_date.getMinutes() : temp_date.getMinutes()) + ':' + (temp_date.getSeconds() < 10 ? '0' + temp_date.getSeconds() : temp_date.getSeconds()) + '.000 GMT+0300', ...rest]

    }); const csv = [csvHeaders, ...temp_changed_date].map((arr) => arr.join(",")).join("\n");

    //const csv = [csvHeaders, ...processedData].map((arr) => arr.join(",")).join("\n"); return csv; }

I hardcoded + '.000 GMT+0300' but this should be set from users input of the offset flag. Also, here we map the entire array after it has been fetched. It would have been better if this was done when creating the array in the first place. Again this 'fix' code is several lines long - I know it could be done more neatly and robustly.

  1. The progress bar displayed for command prompts works fine - but only when viewed directly from the terminal where the downloader is running. If it is called programmatically from another program, and the results outputted to memo, then no progress displays at all. I changed this by adding these two lines of code: a progressBar.start(urls.length, val); process.stdout.write(" Downloading: " + val + " of " + urls.length + " (" + Math.round((val/(urls.length + 0.00000001))100) + "%)\r"); b progressBar.update(val); process.stdout.write(" Downloading: " + val + " of " + urls.length + " (" + Math.round((val/(urls.length + 0.00000001))100) + "%)\r");

This way there is progress also on third party callers. The actual progressBar calling could be changed so that it does not use its own percentage but the text one from above.

Thanks again for this wonderful downloader. Definitely would consider donating.

Leo4815162342 commented 1 year ago

@awakanto first of all thank you for the feedback 😍 - it's highly appreciated.

As for the first 2 suggestions (feature requests), we can definitely implement those changes by allowing more configurable access into how the CSVs are generated, so you can expect those changes to land in the upcoming releases.

As for the progress bar, can you please share how visually that would look, and how you are calling the script from the third party callers? So I could have a better understanding into this feature request.

awakanto commented 1 year ago

Hi Leonid, thanks for the prompt reply. Attached are the requested screenshots. The first is from the third-party windows app, the second is from windows power shell. To call the downloader from the third party app, the command prompt is triggered and the output piped to the application and loaded to a memo as shown. Hope this clarifies a little bit.

Thank you.

Screenshot 2022-10-25 at 22 54 13 Screenshot 2022-10-25 at 22 55 16

Leo4815162342 commented 1 year ago

@awakanto thanks 👍, that makes it clear. I’ll think how we can package this functionality