KQL schema inference bug—[stock-data-sample].[time] field inferred as String in tumbling and SELECT INTO flows; correct only in hopping

Set the Eventstream’s inferred schema—or the Eventhouse destination schema—to datetime for time, then write to a new KQL table because an existing column’s type cannot be changed through the ingestion wizard.

Correct the schema before ingestion

Option 1: Correct the Eventstream inferred schema

If Multiple schema inferencing is available in your Eventstream:

1. Open the Eventstream and select Settings → Schema.
2. Enable Multiple schema inferencing, then select Apply.
   Note: Microsoft documents that this setting cannot be disabled afterward.
3. Enter Edit mode and open Inferred schema.
4. Select the schema associated with the stock-data sample.
5. Change time from string to the timestamp-compatible type shown by the editor, then select Update.
6. On the first node in each path—hopping, tumbling, and direct SQL output—select that corrected schema under Input schema.
7. Select each operator or destination and use View schema to confirm that time has the corrected type before publishing.

Fabric documents that inferred field types can be corrected here and that different transformation paths can otherwise use different inferred schemas. This can explain why the three paths produce inconsistent destination schemas even though they originate from the same stream.^1^

Option 2: Override the type at the Eventhouse destination

If the inferred-schema feature is unavailable or the corrected type is not propagated:

1. Create a new Eventhouse destination and choose a new destination table.
2. In the ingestion configuration, open Inspect the data.
3. Select Edit columns.
4. Map the source time field to a destination column such as EventTime.
5. Set its destination type to datetime.
6. Apply the change, finish the wizard, publish the Eventstream, and verify the new KQL table schema.

The destination wizard supports editing column types for a new table and mapping before ingestion.^2^ A new table is important: Fabric’s ingestion guidance states that existing column types cannot be changed in this workflow; mapping a different format into an existing column can result in empty values.^3^

Before publishing, confirm that all sampled time values use a consistent timestamp representation. Schema inference is sample-driven, so mixed or malformed values can produce another inferred schema.^1^

SQL operator path

The SQL operator uses Azure Stream Analytics query semantics and supports event-time assignment with TIMESTAMP BY. After the input schema identifies the field as temporal, the corresponding pattern is:

SELECT
    symbol,
    price,
    [time] AS EventTime
INTO
    Output
FROM
    Input
TIMESTAMP BY [time];

Use Test query, inspect the output schema, and save only if EventTime is temporal. TIMESTAMP BY assigns event-time semantics; it should not be treated as a documented conversion from an incorrectly inferred string. The SQL operator and its event-time pattern are documented here.^4^

The time name is not enough to establish the cause

KQL permits identifiers that overlap language keywords when they are quoted, although Microsoft recommends avoiding such names. The documented KQL quoting form is ["name"] or ['name'].^5^ Therefore, renaming time to EventTime is a sensible hardening measure, but the current evidence does not establish that time being protected is causing the inconsistent inference.

The hopping/tumbling/direct-output discrepancy is also not listed in the available Microsoft documentation as a known Fabric issue. If all three paths select the same corrected input schema but still create different KQL types, capture:

• Fabric region and capacity/trial type
• Eventstream artifact ID and publishing time
• Input, operator, test-result, and destination schemas
• Minimal SQL for each path
• Newly created destination-table schemas
• Whether Multiple schema inferencing is enabled

Submit those details through Fabric support as a reproducible schema-propagation issue. Avoid testing against existing tables because their fixed schemas can obscure whether the operator output or destination mapping introduced the mismatch.

References

1. Enhance Event Processing with Multiple Schema Inferencing - Microsoft ...
2. Add an Eventhouse destination to an eventstream
3. Get data from Eventstream
4. Process events by using a SQL operator
5. Entity names