Summary

When a field has conflicting date (millis) and date_nanos types across indices, DateMillisToNanosInEsRelation implicitly converts everything to date_nanos. If the user then applies an explicit cast (e.g., ::long, ::date), the Analyzer code extracts the raw inner field from the implicit conversion and wraps it with the new cast, discarding the implicit conversion instead of composing the two.

Repro

FROM sample_data, sample_data_ts_nanos METADATA _index
| EVAL ts = @timestamp::long
| KEEP _index, ts
| SORT _index, ts

Where sample_data has @timestamp as date (millis) and sample_data_ts_nanos has @timestamp as date_nanos.

Expected

Both indices produce consistent values — either all millis-as-long or all nanos-as-long:

_index:keyword       | ts:long
sample_data          | 1698063303360000000
sample_data_ts_nanos | 1698063303360123456

Actual

sample_data produces millis-as-long, sample_data_ts_nanos produces nanos-as-long — off by 10⁶:

_index:keyword       | ts:long
sample_data          | 1698063303360          ← millis (13 digits)
sample_data_ts_nanos | 1698063303360123456    ← nanos (19 digits)

With ::date instead of ::long, sample_data rows show 1970-01-01T00:28:18.063Z (millis interpreted as nanos) when an unmapped index is also present.