Rblapi: upgrade to bloomberg api 3.11.6.1

[albertwufamily]

Quick question on Rblapi: the current version uses bloomberg blpapi 3.8.18.1; meanwhile bloomberg is asking people to upgrade to 3.11.6.1. Is there any plan to release the updated version of Rblapi accordingly?

[Bloomberg did not give a drop dead date for 3.8.18.1 but they have been urging people to switch for a while]

thanks!

[johnlaing]

The public API download page (https://www.bloomberg.com/professional/support/api-library/) still has 3.8.18.1 as supported release, with 3.11.6.1 referenced as experimental.

Are there particular features in the newer version that you're looking for? It should be straightforward for us to upgrade, but I don't see any rush at the moment.

[eddelbuettel]

Also, if you are in a rush you can do the changes locally, test them and then report back. We have to err on the conservative side here.

[albertwufamily]

Thanks, to change locally I would have to re-compile/re-build the rblapi using the new version of Bloomberg api header files and dll. I checked that the new Bloomberg api header files differ from the old ones - meaning I probably have to change the rblapi source code as well....

[johnlaing]

Ideally, the new version will be backwards compatible and all the existing Rblpapi stuff will just work. But we don't know if that's the case until someone tries it. We would encourage you to try it and let us know what happens.

[lomiarzpraca]

hello, is there any update on the horizon? the new bloomberg api gives an opportunity to get ticks with milliseconds in timestamp. You can check this possibility in api demo tool. Is there any chance to get ticks with same miliseconds to R? Thanks for reply.

[johnlaing]

I just pushed a branch "experimental" which builds with the newer version of the API 3.11.6.1. The package compiles but does not pass checks, so our previous suspicion is confirmed: there is more work to be done here. As always, code contributions are welcome.

[Courvoisier13]

Hi, I don't know if this is of interest to anyone. It seems to me right now that there 2 issues here:

1. The bloomberg API demo test (BlpApiDiagnosticsTool.exe) shows microsecond accuracy for European stocks. Look at Text View Results for VOD LN Equity. (the default IBM US shows only seconds accuracy). So the API should indeed return microseconds accuracy.

2. I edited the getTicks.cpp and the blpapi_utils.cpp and added time as is in the verbose sections and also added time.milliseconds() and time.microseconds() on the line 112. Both of these show millisecond accuracy, However this millisecond seems to gets lost on line 120 when transformig the time to a Posixt in ticks.time.push_back(bbgDatetimeToUTC(time)); I added another variable timeStr for time as string and that showed me the full time with milliseconds. Furthermore, in blpapi_utils.cpp, I changed bbgDatetimeToUTC and bbgDatetimeToPOSIX to use microseconds, but that did not do anything (and used bbgDatetimeToPOSIX instead of bbgDatetimeToUTC in getTicks but that didn't change the R posixct output.

So there are 2 issues:

1. The API itself seems to be giving milliseconds not microseconds as the demo tool does or there is something in the cpp code that I am missing.
2. The casting into Posixt (the bbgDatetimeToUTC function) is cutting out the milliseconds.

I will keep investigating and see if I can fix it and submit an update. As worst we can just output the field as text and do the casting in R.

thanks

[johnlaing]

This is good and likely useful to somebody. Please open a new issue if you're able to make progress here or for further discussion.

[Courvoisier13]

I made some progress, but need some advice because I am not that familiar with the boost::posix_time::time_duration class.

In function bbgDatetimeToUTC I changed boost::posix_time::time_duration::sec_type x = (bbg_ptime - epoch).total_seconds() to boost::posix_time::time_duration::fractional_seconds_type x = (bbg_ptime - epoch).total_microseconds(); However, this needs to be divided by 1000000.0 and that brings it back to a fraction of a second. But the fractional_seconds_type object seems to be an integer and doesn't accept that. So I just did

double x_s = x/1000000.0;
return x_s;

and that worked and I can see milliseconds in the data.frame output.

Let me know if you see there is any issues in doing that. Or if there is a better way by keeping the boost::posix_time::time_duration objects as outputs.

[eddelbuettel]

I can help you there (even if I am without Bloomberg access these days). In very early days Rcpp may have imposed an int, it no longer does. Let's see if we can distill this into a small self-contained example to noodle over. But in essence package anytime does a lot around POSIXct. The 'newer' Datetime objects are also in RQuantLib and other places.

We should be able to work with 'what we get' from Bbg -- if it is better than second we can surely pass it on. Bbg itself may have constraints from the exchanges and what not.

[Courvoisier13]

Ok thank you, Let me see what I end up with. I also added includeNonPlottableEvents = true includeBicMicCodes = true the request to get venue MICs. And I would have loved to get the field "tradeTime" as is given in the demo API tool. but when I add includeTradeTime = true don't get that back and that could be an API version issue. I think that field is the TAG60 (exchange timestamp, as opposed to recorder timestamp) and that's very valuable. So let me see with Bloomberg and see what they say on 1- the microsecond, 2- the tradeTime and this way upgrade several properties of this function.

[Courvoisier13]

So for 2- trateTime we need to be using the newer API. The current supported one is v3.12.3.1. For the 1- microsecond I think it's the same but i am not sure. I need to do more work to see if we can use the API v3.12.3.1