Marten项目中的DateTimeOffset时区支持问题解析

背景介绍

Marten是一个基于PostgreSQL的.NET文档数据库和事件存储库。在最新版本中，开发人员发现当使用LINQ查询包含时区偏移的DateTimeOffset类型时会出现异常，而使用UTC时间则能正常工作。这个问题涉及到PostgreSQL的时间类型处理机制。

问题本质

PostgreSQL的"timestamp with time zone"类型实际上并不存储时区信息，它只是将输入时间转换为UTC存储，并在检索时根据当前时区设置转换回本地时间。当使用带有非UTC偏移的DateTimeOffset进行LINQ查询时，Npgsql驱动会抛出异常，明确指出只支持UTC偏移量为0的情况。

技术分析

问题的核心在于PostgreSQL和Npgsql驱动对时间类型的处理方式：

1. PostgreSQL的"timestamp with time zone"类型本质上是一个UTC时间戳
2. Npgsql驱动强制要求写入的时间偏移必须为UTC(+00:00)
3. Marten目前没有在LINQ查询中自动处理时区转换

解决方案探讨

开发团队提出了几种可能的解决方案：

1. 自动转换方案：让Marten在构建NpgsqlCommand时自动将DateTimeOffset转换为UTC时间。这种方案实现简单，但可能会隐藏潜在的时区问题。

2. 显式处理方案：要求开发人员在代码中显式处理时区转换。这种方案更透明，但增加了使用复杂度。

3. 使用NodaTime替代方案：NodaTime提供了更丰富的时间类型支持，但LINQ支持较为复杂。

最佳实践建议

基于技术讨论，我们建议：

1. 对于简单场景，在查询前手动将DateTimeOffset转换为UTC时间：

DateTimeOffset queryTime = DateTimeOffset.Now.AddDays(-1).ToUniversalTime();

2. 对于需要完整时区支持的场景，考虑使用NodaTime库：

// 存储时区标识和UTC时间
var ianaTimeZone = "Europe/Paris";
var utcTime = DateTimeOffset.UtcNow;

3. 在设计阶段明确时间比较逻辑，避免隐式时区转换带来的混淆。

结论

Marten项目中DateTimeOffset的时区支持限制反映了PostgreSQL时间类型的本质特性。开发人员应当根据应用场景选择合适的时间处理策略，显式处理时区问题通常比隐式转换更可靠。对于需要复杂时区支持的场景，NodaTime提供了更专业的解决方案，但需要权衡其复杂性。