Skip to content

← Training overview

7. TimeManager

A feature engineered today on yesterday's data is fine — but training a model needs the feature as it was a year ago, not a recomputation of today's logic on yesterday's snapshot. TimeManager replays your registered processes at historical business times so the feature store accumulates a real time series.

Why replay history

  • Point-in-time correctness. The model trains on what the entity actually looked like at the prediction date, not today's value of an attribute that has since drifted.
  • Reproducibility. A future audit can read the feature value as of any past date by setting FEATURE_STORE_TIME to that date.
  • No data leakage. The features registered for date t only see source data available at or before t.

tdfs4ds separates two clocks: business time (the date you are materialising) and system time (Teradata VALIDTIME, when the row was written). See Concepts › Temporal model for the full mental model.

How to use it

from tdfs4ds.utils.time_management import TimeManager

bt = TimeManager(table_name='FS_BUSINESS_TIME', schema_name=tdfs4ds.SCHEMA)
bt.load_time_steps(df_calendar, date_column='AS_OF_DATE')  # one-time setup

tdfs4ds.roll_out(
    process_list=[process_id_1, process_id_2],
    time_manager=bt,
    time_id_start=1,
    time_id_end=bt.nb_time_steps,
)

roll_out iterates each registered process across every business time in the manager. Manual stepping works too — set tdfs4ds.FEATURE_STORE_TIME to the desired past date and call run(process_id).

Cloning a TimeManager

When multiple processes share the same date calendar, clone the timer rather than loading it again:

bt_p2 = TimeManager(table_name='FS_BT_PROCESS2', schema_name=tdfs4ds.SCHEMA)
bt_p2.clone_timer(bt_source)          # soft clone — view points to source hidden table

A soft clone creates only a new view (no data copied). A hard clone (clone_mode='hard') copies the hidden table into this schema; the clone is fully independent and can evolve separately. take_ownership() promotes ownership of the shared table when a soft-clone manager should be responsible for cleanup.

See the TimeManager user guide for if_exists options and the create_copy / take_ownership details.

Composing with FilterManager

Both managers are independent and stack. A common pattern: TimeManager for the when, FilterManager for the what — replay each historical date segment-by-segment so a single chunk of work fits in memory. When multiple processes share both the same date calendar and different partition filters, soft-clone the timer for each process and attach the relevant FilterManager to each roll_out call.

Learn more