@pond-ts/financial API Reference
    Preparing search index...

    Type Alias SessionAnchorOptions<S>

    SessionAnchorOptions:
        | {
            session?: never;
            sessions: SessionSource;
            stamped?: "open"
            | "close";
        }
        | {
            session: NumericColumnNameForSchema<S>;
            sessions?: never;
            stamped?: never;
        }

    The session anchor — how sessionVwap and pivotPoints are told where their sessions are. Exactly one of the two doors is given; passing both, or neither, throws.

    A calendar (or a session list). A calendar is asked for the sessions overlapping the series' own key range (sessionsInRange); a raw list is validated and sorted on every call — cheap, but not narrowed. Either way the bars are walked against the sessions once, O(N + sessions) with the session cursor only moving forward. This is the door the trading-calendar RFC's §6.1 picture points at: one calendar object shared by the data ops, the bar building and the axis, so a study and a chart cannot disagree about where a session starts.

    The name of a session-id column already on the series. It is what TradingCalendar.tagSessions(series) appends, and a consumer who followed the RFC's partitionBy(sessionId) stopgap already has it — asking them to hand the calendar back in would mean walking it twice. Any numeric column works: a run of one value is one session, undefined is closed time. The two doors are the same anchoring by construction — tagSessions and the sessions door call the same sessionIdValues walk — and a test pins the two routes equal under both stamp conventions.

    Belongs to the sessions door only: it is how a bar instant is placed against a session edge, and a session-id column has already had that decision applied to it (pass stamped to tagSessions instead). Passing it beside session throws rather than being silently ignored.

    The type is a discriminated union, so { sessions, session }, { session, stamped } and {} are compile errors (a Layer-2 review of #715 found all three only threw at runtime); the runtime checks stay for a caller who arrives through as never.

    A session with intraday breaks (a lunch halt) is one session here: a session VWAP spans both halves and a pivot ladder reads the whole day's high / low / close, which is what every venue that publishes them means. A bar printed inside a break — a data quirk, not a trade — is therefore tagged in-session rather than as closed time. Closed time is the gap between sessions, an overnight print, a weekend bar on a 24/7 feed, or an instant outside the schedule's range.

    Type Parameters

    • S extends SeriesSchema

    Type Declaration

    • { session?: never; sessions: SessionSource; stamped?: "open" | "close" }
      • Optionalsession?: never
      • sessions: SessionSource

        The trading calendar, or an explicit session list. The primary door. Mutually exclusive with session.

      • Optionalstamped?: "open" | "close"

        Bar-stamp convention for the sessions door — 'open' (default) treats a session as [open, close), 'close' as (open, close].

    • { session: NumericColumnNameForSchema<S>; sessions?: never; stamped?: never }
      • session: NumericColumnNameForSchema<S>

        The name of a session-id column already on the series (what TradingCalendar.tagSessions appends). Mutually exclusive with sessions; stamped does not apply (pass it to tagSessions).

      • Optionalsessions?: never
      • Optionalstamped?: never