SDK5.2.2: clarify HK candle endpoints, daily trading-date labels and revision/adjustment semantics

Đang mở
  • Có gì không ổn?
#1,302 1 bình luận 0 reaction 0 người được giao Xem trên GitHub

Maintainer thường phản hồi trong vòng 1 ngày

Chưa có ai nhận issue này.

Đánh giá

Độ khó
4/5
Thời gian dự kiến
3-5 ngày
Mức phù hợp với người mới
48/100
Loại issue
Tài liệu
Độ rõ ràng
Đặc tả rõ ràng
Mức độ hoạt động
Sôi nổi
Công nghệ
openapi, python
Lĩnh vực
documentation

Hướng nghiên cứu

Start with the OpenAPI definitions and SDK handling for history_candlesticks_by_date, PushCandlestick.is_confirmed, AdjustType, and TradeSessions, then review the discussions in #728, #675, #784, and #1152. Compare the server contract with version-specific Python 5.2.2 behavior for HK/US endpoints, timestamps, revisions, and adjustments. Done means each of the five numbered questions has an authoritative answer that distinguishes guaranteed behavior, current implementation, and known limitations, with links to relevant documentation or specifications.

Do mô hình lập chỉ mục viết ra từ nội dung của issue.

Mô tả

Singapore support directed this OpenAPI semantics inquiry to the developer tracker. Please route it to the market-data/SDK engineering team. This concerns a research-only application; no account lookup or trading operation is requested.

Environment and bounded observations

Python package longbridge==5.2.2, Windows x64. Historical calls use history_candlesticks_by_date, AdjustType.NoAdjust, TradeSessions.Intraday, and the same explicit start/end date. No raw OHLCV, credentials, account identifiers, authentication details or attachments are included.

For each case below, two independent method calls returned identical ordered timestamp/content-digest observations:

Symbol / date Period Observed metadata
700.HK, 2026-10-22 Min_1 331 unique rows; 09:30, 11:59, 13:00 and 15:59 HKT present; 12:00 absent; 16:00 present
700.HK, 2026-02-16 (HK half-day) Min_1 151 unique rows; 09:30, 11:59 and 12:00 HKT present
700.HK, 2026-10-22 Day One row timestamped 2026-10-22 00:00 HKT, equivalent to 2026-10-21 16:00 UTC

We retain the endpoint rows and original timestamps. We do not force 330/150 rows, synthesize missing bars, or infer full coverage or immutable finality from matching samples. In a separate HK minute comparison, one SDK-confirmed callback differed from two matching history observations; a later sample matched all six OHLC/volume/turnover fields. The older combined digest cannot identify the differing field, so the later match is not treated as an explanation or general guarantee.

Engineering questions

  1. HK minute endpoints and auction composition. For Min_1/Intraday/NoAdjust, what precise trade interval and trade types contribute to the 16:00 full-day row and 12:00 half-day row? Are these auction buckets, cumulative final snapshots, clamped labels or another interval? Please specify opening auction, lunch-break and closing-auction inclusion and whether the timestamp denotes the start or end of that interval.
  2. US endpoints and calendar rules. Does the documented 2024-11-29 US closing-row change apply identically to historical responses and SDK-confirmed candles? Please specify regular/early-close endpoints and venue/DST rules. No new US experiment is being requested or claimed here.
  3. Confirmation, revisions and history/push consistency. What does Python PushCandlestick.is_confirmed guarantee, and what can still revise afterward? Can OHLC, volume or turnover differ between a completed SDK candle and same-key history? What retrieval timing, correction/revision indicator, data version or reconciliation procedure should clients use, including after reconnect?
  4. Daily timestamp versus exchange trading date. Is the observed HK venue-midnight label a supported server contract? What are the exact HK and US daily timestamp/timezone and trading-date assignment rules for historical requests, including early-close/DST dates? Please distinguish server history behavior from SDK-local daily construction and UTC date formatting.
  5. Adjustments and auditable events. Please document NoAdjust versus ForwardAdjust split/cash-dividend factors, price/volume/turnover treatment, factor effective/as-of dates and historical restatement policy. Is there an auditable market-data factor/event source with version/effective-date provenance? We will not infer factors from sampled prices or invent event dates.

We have read the callback-frequency discussion in #728: minute grouping is distinct from push frequency. It does not answer completed-candle finality or historical correction semantics. #675 concerns serialization of daily examples, #784 discusses a timestamp example, and #1152 contains data-quality/revision questions; we are not treating issue examples or reporter expectations as the server contract.

Please provide authoritative documentation or a version-specific engineering answer for each numbered question, distinguishing guaranteed behavior from current implementation and known limitations. If separate issues are preferred, please identify the appropriate maintainers/category. We can supply additional sanitized metadata later; no new sampling or private material is authorized by this inquiry.

Ngôn ngữ chính
TypeScript
Star
61
Fork
30
Merge trung bình
7 giờ 45 phút
Pull request đã merge (30 ngày)
17

Chuẩn bị môi trường

Bắt đầu từ đâu

  1. Đọc hết issue, rồi đọc hướng dẫn đóng góp của dự án.
  2. Bình luận trên issue rằng bạn sẽ nhận — tránh hai người làm cùng một việc.
  3. Fork repository và làm thay đổi trên một nhánh.
  4. Mở pull request có tham chiếu số hiệu của issue.

Issue khác của longbridge/developers

Tất cả issue của longbridge/developers

Issue tương tự

Thêm issue về TypeScript

Nhận issue mới trong hộp thư của bạn

Bản tóm tắt ngắn những issue GitHub phù hợp với người mới.