彭博報價數據時區偏移
我正在使用 python 來訪問 Bloomberg Desktop API，並且遇到了他們的刻度數據的時區轉換問題。
他們提供的數據應該是 UTC，但是發生了一些奇怪的事情，有些數據似乎被一天抵消了。有關詳細資訊，請參閱下面的對話-我已經嘗試過，但似乎沒有用。到目前為止，我無法在偏移量中找到模式：
你好 *******，
因此，偏移量是正數還是負數，取決於 GMT 是領先於還是落後於交易所時區。所以從這個意義上說，我總是從 API 中獲取小時，將其與偏移量相加，如果我們大於 24 小時，則添加一天並以 24 為模 - 否則如果我們小於 24 小時，我會取負數數加上24，再減去一天。
沿著這些構想的東西應該在這裡解決問題。
如有任何問題，請與 H#******* 聯繫 - 保重，
彭博幫助
如需更多幫助：按兩次 鍵。參考 H#******* 繼續此查詢。
*******@bloomberg.net
您的問題是： Re:H#****** 將 GMT 調整為本地交換時間
這個怎麼樣：
取API返回的GMT時間戳，取小時，減去偏移量……如果結果小於0，轉換為EST後需要將日期向前調整1嗎？聽起來對嗎？
來自：HELP DESK (BLOOMBERG) 時間：2015 年 5 月 11 日 11:21:18 主題：Re:H#******** 將 GMT 調整為本地交換時間
你好 *******，
從周五開始繼續我們的談話。最終，我們需要做的是使用 TIME_ZONE_NUM 欄位拉入偏移量，並在您的程式碼中添加一些邏輯來調整我們可能會在這裡超過 24 小時的事實。
一種方法是採用 GMT + 偏移量模 24 來獲得第二天的小時 - 然後結合我們也需要調整這一天的事實。
如有任何其他問題，請與 h#******** 聯繫。
祝你有個好的一天，
彭博幫助
如需更多幫助：按兩次 鍵。參考 H#******** 繼續此查詢。
您的問題是：我正在為 8035 JP Equity 獲取 API TickData ….時區轉換似乎有些奇怪。例如…我在 2015 年 1 月 8 日 23:00:07 在我的終端中查看交易
$$ 600 shares @ 8670 $$EST….當我通過 IntraDayTick API 函式提取相同的交易時，交易報告為 01/08/15 的 04:00:07（這是 UTC/GMT）。但是，將其轉換為 EST 將是 15 年 1 月 7 日的 23:00:07，而不是 15 年 1 月 8 日……這是怎麼回事？
想知道是否有人遇到過類似的問題/已經解決了這個問題？這對我來說似乎很奇怪，這不清楚。
更新：
這是問題的完整範例：
在終端：
8035 JP Equity QR: FROM: 23:00:07 01/08/2015 TO: 23:00:07 01/08/2015退貨交易：
Time: 23:00:07, Size: 600, Price: 8670這裡的日期/時間是**
EST 23:00:07 01/08/2015**通過 API 進行相同的交易
IntradayTickRequest：tickData = {TIME = 2015-01-08T04:00:07.000 TYPE = TRADE VALUE = 8670.000000 SIZE = 600}這裡的日期/時間是
UTC 04:00:07 01/08/2015，轉換後的（使用http://www.timezoneconverter.com/）是**ETC 23:00:07 01/07/2015**所以終端和 API 報告某些交易的不同日期，我正在尋找某種規則來標準化數據。
事實證明，彭博終端
QR功能在將時區從 Exchange/UTC 調整為您的時區時，將轉換時間而不是日期。通過
IntradayTickRequestAPI 顯示的交易在 UTC 時間是正確的，通過彭博終端顯示的交易QR可能由於未能調整規定的日期以進行時區調整而不正確。
“某些數據被一天抵消”：您沒有提供足夠的詳細資訊來說明哪些安全/數據以及涉及的時間。
這可能與日曆日期和交易時段日期之間的差異有關。例如，標準普爾期貨在紐約時間週日下午 6 點開始交易。然而，這被認為是周一會議的一部分。因此，您必須清楚實際日期和交易時段日期。週一營業日週日有交易。
此外，不要只與彭博幫助台交談，嘗試聯繫 API 專家。
高溫高壓