fix: Adds mapping of date Trino's type into string Feast's type

[soliverr]

Minor change: just adds date Trino's type to supported Feast's types

---

[devin-ai-integration]

Devin Review found 1 potential issue.

View 3 additional findings in Devin Review.

[devin-ai-integration]

🔴 Trino date type mapped to ValueType.STRING instead of ValueType.UNIX_TIMESTAMP

The PR maps Trino's date type to ValueType.STRING, but this is inconsistent with every other type mapping in the Feast codebase and with the Trino type map's own PyArrow mapping.

Root Cause and Impact

Every other date-to-Feast-ValueType mapping in the codebase uses ValueType.UNIX_TIMESTAMP:

• sdk/python/feast/type_map.py:224: "date": ValueType.UNIX_TIMESTAMP (pandas)
• sdk/python/feast/type_map.py:969: "date": ValueType.UNIX_TIMESTAMP (MSSQL)
• sdk/python/feast/type_map.py:1164: "date": ValueType.UNIX_TIMESTAMP (Spark/Hive)
• sdk/python/feast/type_map.py:1258: "date": ValueType.UNIX_TIMESTAMP (Postgres)

Additionally, within the same file at trino_type_map.py:94, the _TRINO_TO_PA_TYPE_MAP maps "date" to pa.date32() (a date/temporal type), not pa.string(). This creates an internal inconsistency: trino_to_feast_value_type("date") returns STRING while trino_to_pa_value_type("date") returns pa.date32().

Impact: Features sourced from Trino date columns will be incorrectly typed as STRING in the Feast feature schema, which can cause type mismatches during feature retrieval, materialization, or when joining with features from other offline stores that correctly type date as UNIX_TIMESTAMP.

Suggested change

	"date": ValueType.STRING,
	"date": ValueType.UNIX_TIMESTAMP,

---

Was this helpful? React with 👍 or 👎 to provide feedback.

[soliverr]

Trino's date type looks like a string in a format 'YYYY-MM-DD'. I think, it is clearer to map the date type into string