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

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.

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:

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.