A Price Is Not Yet a Fact: Time, Phase, and Partial Bars

For zhulinsen/daily_stock_analysis, the meaning of a price depends on when and where it was observed. This chapter focuses on the project’s market-phase lifecycle: how local calendars determine the usable daily bar, how realtime observations become partial or estimated context, and how those states change the language and confidence of the decision dashboard. The result is a practical distinction between a completed market fact and a current observation that still needs confirmation.

Without that distinction, an automated report can be numerically correct and still temporally wrong. A price seen during a session may be real, but the session is not finished. A server running after midnight may be on a different calendar date from the exchange that supplied the data. A caller may request an intraday framing, but that request cannot manufacture a completed bar. DSA treats these as state and boundary problems rather than leaving them to the model’s intuition.

The clock belongs to the market

A single wall clock is not enough for a multi-market analysis system. DSA associates each market with an exchange calendar and a local timezone, so “today” is resolved in the market’s own frame. A-shares use China time, Hong Kong uses Hong Kong time, US stocks use New York time, and the Japanese, Korean, and Taiwan paths use their respective local zones. The point is not the names of the zones; it is ownership. The exchange session owns the meaning of a trading date, not the machine that happens to run the Python process.

The calendar layer supplies more than a trading-day yes/no answer. Its MarketPhaseContext records the market-local timestamp, session date, effective daily-bar date, whether the market is a trading day, whether it is open, whether the current bar is partial, and the approximate minutes to the next opening or closing boundary. It also carries the trigger source and warnings such as an unknown market or unavailable calendar. This context is created before the dashboard is generated, so later prompts and guardrails do not have to guess whether a value belongs to a completed session.

The most important field is the effective daily-bar date. On a trading day before the regular session closes, the current session is still unfinished, so the reusable daily bar is the previous completed session. After the close, the current session can become the reusable daily bar. On a non-trading day, the system looks back to the previous trading session. If calendar lookup fails, the project has a documented fail-open fallback to the market-local natural date for effective-date logic, while phase inference can become unknown. That fallback keeps the process from crashing, but it does not prove that a complete bar exists.

This rule protects several downstream operations at once. Trend calculations need a stable historical window. Resume logic needs to know whether data for the relevant session already exists. Backtests and outcome evaluation need an analysis date that does not move simply because the program was started at a different time.