Concepts

Daily windows (local standard time)

A daily high or low belongs to the station’s local-standard calendar, not the raw UTC date on the report. Mostly Right maps each report to a fixed local-standard-time day using the station registry, then uses that key consistently in observations, labels, and training tables.

Local standard time, not UTC

Local-standard days use the station’s standard UTC offset, without daylight-saving shifts. This keeps the daily window 24 hours long across DST transitions and matches the convention used by daily climate products.

For KNYC, the settlement offset is UTC−5 even while New York civil clocks observe daylight time.

Map a timestamp

The 2.0 helper is weather.local_standard_date_for():

from datetime import datetime, timezone
from mostlyright import weather

weather.local_standard_date_for(
    "KNYC",
    datetime(2025, 7, 15, 2, 0, tzinfo=timezone.utc),
)
# "2025-07-14"

weather.local_standard_date_for(
    "KNYC",
    datetime(2025, 7, 15, 7, 0, tzinfo=timezone.utc),
)
# "2025-07-15"

Station comes first and the timestamp must be timezone-aware.

To inspect the UTC bounds of one local-standard day:

start_utc, end_utc = weather.local_standard_date_window_utc(
    "KNYC",
    "2025-07-15",
)

The interval is half-open: [start_utc, end_utc).

Why UTC bucketing is wrong

A KNYC report at 2025-07-16T03:51:00Z is still on the evening of July 15 in EST:

Rule	Bucket	Result
Raw UTC date	2025-07-16	Wrong local-standard day
Station local standard date	2025-07-15	Correct

The same issue appears in the opposite direction for positive-offset stations. For Tokyo, a report at 2025-07-14T15:00:00Z belongs to the July 15 local-standard day.

Where the date appears

weather.observations() returns per-report rows and attaches local_standard_date to each one:

reports = weather.observations(
    "KNYC",
    "2025-07-15",
    "2025-07-15",
)

reports[["event_time_utc", "local_standard_date"]]

weather.training_table() aggregates those reports to one row per station and local_standard_date, with the settlement label and timing columns beside the features:

table = weather.training_table(
    "KNYC",
    "2025-07-15",
    "2025-07-15",
)

The old bare date key and market_close_utc column are not the 2.0 contract. Use local_standard_date, decision_time_utc, and label_available_time_utc.

Boundary widening

A daily read may fetch beyond the caller’s two UTC-midnight boundaries so the first and last local-standard days are complete. After reports are mapped to the station calendar, output is clipped back to the requested local-standard dates.

request: 2025-07-15 through 2025-07-15
fetch:   includes the UTC tail needed to complete that local-standard day
bucket:  map every report with local_standard_date_for(...)
output:  rows whose local_standard_date is 2025-07-15

This widening is an implementation detail. Do not reproduce daily aggregation by slicing event_time_utc[:10].

Contract calendars

The generic 1.x days() helper was removed. Use:

weather.training_table() for one supervised row per station/local-standard day
markets.kalshi.settlement_days() for a Kalshi contract calendar
markets.polymarket.settlement_days() for a Polymarket event calendar
weather.observations() when you need the underlying reports