2
$\begingroup$

I am using python to access the Bloomberg Desktop API and am running into issues with the timezone conversion for their tick data.

The data they deliver is supposed to be UTC but there is something strange going on where some data seems to be offset by a day. See the below conversation for details-- I have tried this but it doesnt seem to be working. I haven't been able to find a pattern in the offset so far:

Hi *******,

So the offset comes in either positive or negative depending on whether or not GMT is ahead or behind the exchange time zone. So in that sense, I would always grab the hour from the API, sum that with the offset, if we're > 24 hours then add a day and modulo 24 - else if we're < 24 hours, I would take that negative number and add it to 24, and subtract a day.

Something along those lines should do the trick here.

Please reach out with H#******* with any questions - take care,

Bloomberg Help

For further help: Press the key twice. Reference H#******* to continue this inquiry.

*******@bloomberg.net

Your question was: Re:H#****** Adjusting GMT to local exchange time

How about this:

Take GMT timestamp returned by API, take the hour, subtract the offset....if the result is less than 0, need to adjust the date forward by one after converting to EST? Does that sound right?

From: HELP DESK (BLOOMBERG) At: May 11 2015 11:21:18 Subject: Re:H#******** Adjusting GMT to local exchange time

Hi *******,

Following up on our conversation from Friday. Ultimately what we'll need to do is pull in the offset with the TIME_ZONE_NUM field, and add some logic to your code to adjust for the fact that we may go over 24 hours here.

One way to do that would be by taking the GMT + offset modulo 24 to get the hour on the next day - then incorporate the fact that we will need to adjust the day forward as well.

Please reach out with h#******** with any further questions here.

Have a good one,

Bloomberg Help

For further help: Press the key twice. Reference H#******** to continue this inquiry.

Your question was: I am getting API TickData for 8035 JP Equity....something seems be wierd with the timezone conversion. For example...I am looking at a trade in my Terminal at 23:00:07 on 01/08/15 [600 shares @ 8670] EST....when I pull the same trade through teh IntraDayTick API function the trade is reported as 04:00:07 on 01/08/15 (THIS IS UTC/GMT). However converting this to EST would be 23:00:07 on 01/07/15, not 01/08/15....what is going on?

Wondering if anyone has had a similar issue / has solved this? Seems strange to me that this is not clear.

UPDATE:

Here is the full example of the problem:

In the Terminal:

8035 JP Equity QR:

FROM: 23:00:07 01/08/2015
TO: 23:00:07 01/08/2015

Returns Trade:

Time: 23:00:07, Size: 600, Price: 8670

The Date/Time here is EST 23:00:07 01/08/2015

The same trade via API IntradayTickRequest:

tickData = {TIME = 2015-01-08T04:00:07.000
    TYPE = TRADE
    VALUE = 8670.000000
    SIZE = 600}

The Date/Time here is UTC 04:00:07 01/08/2015, which converted (using http://www.timezoneconverter.com/) is ETC 23:00:07 01/07/2015

So the Terminal and API are reporting different days for certain trades, I am looking for some sort of rule to standardize the data.

Improve this question
$\endgroup$
4
  • $\begingroup$ Yes it's a bit of a mess - even looking at QR/QRM sometimes gives weird results... $\endgroup$
    – assylias
    Commented May 28, 2015 at 9:17
  • $\begingroup$ Have you found a straightforward rule for dealing with this? The solution they gave me doesn't make any sense. $\endgroup$
    – baconwichsand
    Commented May 28, 2015 at 12:24
  • $\begingroup$ No I'm afraid.. If I do find something I'll let you know, but won't be soon... Maybe somebody else has an answer. $\endgroup$
    – assylias
    Commented May 28, 2015 at 13:11
  • 1
    $\begingroup$ Ok...will spend some time over the next week trying to figure this out...will post if I find something $\endgroup$
    – baconwichsand
    Commented May 28, 2015 at 13:21

2 Answers 2

Reset to default
5
$\begingroup$

It turns out that the Bloomberg Terminal QR function, when adjusting the timezone from Exchange/UTC to your timezone, will convert the time but not the day.

Trades displayed via IntradayTickRequest API are correct in UTC time, trades displayed via Bloomberg Terminal QR may be incorrect due to failure to adjust the stated date for timezone adjustments.

Improve this answer
$\endgroup$
2
  • $\begingroup$ Wow that's scary - thanks for sharing your results. $\endgroup$
    – assylias
    Commented Jun 5, 2015 at 18:25
  • $\begingroup$ "will convert the time but not the day" Has it been improved/changed since then? I can't say I have issues with the tickers I'm using, but I would like to be sure I have it all under control.. $\endgroup$
    – tagoma
    Commented Apr 28, 2021 at 20:40
0
$\begingroup$

"some data is offset by a day": you don't give enough detail about what security/data and what time is involved.

This may have to do with the difference between the calendar date and the trading session date. For example S&P futures begin trading at 6pm new york time on Sunday. However that is considered part of the monday session. So you have to be clear about the actual date and the trading session date. There is trading on Sunday for the Monday business date.

Also, don't talk only to the general Bloomberg help desk, try to reach an API specialist.

HTH

Improve this answer
$\endgroup$
1
  • 1
    $\begingroup$ I added an update to my post, hope that explains what I am confused....I am trying to reconcile my program's data with the Terminal $\endgroup$
    – baconwichsand
    Commented May 28, 2015 at 15:24

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.