Kusto外部表datetime字段0001年日期显示为2001年的原因及解决方法

Kusto查询引擎读取CSV格式外部表时，对/分隔的日期字符串默认优先匹配两位年份的短日期格式，内置世纪自动补全规则为：两位年份值在00-29区间时自动映射为2000-2029年，30-99区间时自动映射为1930-1999年。
当源CSV中存储的日期值为01/01/0001 00:00:00时，默认解析逻辑未正确识别4位长度的0001为完整年份字段，错误截取最后两位01作为年份值，触发上述世纪补全规则，最终返回2001-01-01 00:00:00的错误结果。
Kusto的datetime类型原生支持的最小取值为0001-01-01 00:00:00，该问题不属于类型范围限制，仅为默认解析逻辑的格式匹配优先级问题。

按落地成本从低到高可选择以下三种方案：

方案1：建表时显式指定日期解析格式 #

创建/修改外部表定义时，针对CSV格式显式指定datetime列的解析格式字符串，强制解析器按4位年份规则匹配，跳过两位年份自动补全逻辑。
建表示例核心片段：

.create-or-alter external table MyExternalTable (
    // 其余业务列定义
    lastModifiedDate: datetime
)
kind=storage
// 存储连接、分区配置省略
dataformat = csv
(
    // 核心配置：按源数据实际分隔顺序填写，月在前用MM/dd/yyyy，日在前用dd/MM/yyyy
    csvDateTimeFormat = "MM/dd/yyyy HH:mm:ss"
)

注意：需根据源CSV实际的月、日排列顺序调整格式字符串，避免月日解析错位

方案2：查询阶段手动转换日期值 #

如果不方便修改已上线的外部表定义，可将目标列先以string类型定义，查询时通过datetime_pattern函数按指定格式手动做类型转换，绕开默认解析逻辑。
查询示例：

external_table("MyExternalTable")
// 假设建表时lastModifiedDate列定义为string类型
| extend lastModifiedDate_parsed = todatetime(datetime_pattern("MM/dd/yyyy HH:mm:ss", lastModifiedDate))
// 后续业务查询逻辑

方案3：源端统一日期格式 #

如果数据生产链路可控，直接将源CSV中的日期值统一调整为ISO8601格式（即yyyy-MM-dd HH:mm:ss，对应值为0001-01-01 00:00:00）。该格式为Kusto datetime类型解析的最高优先级格式，无格式匹配歧义，兼容性最好。

内容的提问来源于stack exchange，提问作者boa_hancock