disable_event_timestamp is plumbed into MaterializationTask but no materialization engine reads it #6936

Expected Behavior

FeatureStore.materialize(..., disable_event_timestamp=True) — and the feast materialize --disable-event-timestamp CLI flag and the feature server's disable_event_timestamp request field that call it — are documented as "materializes all available data using current datetime as event timestamp" (feature_store.py ~L2858, infra/provider.py ~L246). Rows written to the online store under this flag should carry the materialization time as their event timestamp.

Current Behavior

The flag is threaded all the way down (feature_store.py → provider → MaterializationTask.disable_event_timestamp in infra/common/materialization_job.py ~L25) and then nothing reads it: grep -rn disable_event_timestamp sdk/python/feast/infra/materialization sdk/python/feast/infra/compute_engines returns no hits. The source's own event timestamp is written unchanged.

Repro (local provider, sqlite online store, a FileSource whose row is stamped 2020-01-01):

feast apply
feast materialize --disable-event-timestamp
# then get_online_features(...).to_dict(include_event_timestamps=True)

returns event_timestamp = 1577836800 (2020-01-01) for the materialized row — the source value, not the current time.

The flag's other effect — widening the materialization window to "everything" — does happen (and has a separate timezone bug in how it computes the end bound, which I'm sending as a small PR). This issue is only about the documented "use current datetime as event timestamp" behaviour never having been implemented since the flag landed in eb51f00.

Steps to reproduce

1. feast init a local repo; point a FeatureView at a parquet FileSource with one row whose event_timestamp is 2020-01-01.
2. feast apply && feast materialize --disable-event-timestamp
3. Read the row back with get_online_features(...).to_dict(include_event_timestamps=True).
4. Observe the 2020 timestamp.

Specifications

• Version: 0.66.1.dev72+g97296c19f (master @ 97296c1)
• Platform: macOS, Python 3.13
• Subsystem: materialization (local engine; the flag is unread by every engine under infra/materialization/ and infra/compute_engines/)

Possible Solution

Either implement it — have the materialization engines overwrite the event timestamp column with _utc_now() when task.disable_event_timestamp is set, before the online write — or drop the "current datetime" promise from the three docstrings and let the flag mean only "full window". The first is the documented contract; happy to take it on if a maintainer confirms which engines should honour it (local only, or all).