Linux部署的.NET Core应用转换UTC时区后DateTime Kind未指定问题

问题原因 #

TimeZoneInfo.ConvertTimeFromUtc方法的设计就是返回Kind = DateTimeKind.Unspecified的DateTime对象——因为转换后的时间属于目标时区的本地时间，既不是UTC，也不是当前系统默认的本地时区时间，所以.NET不会为它指定具体的Kind值，这个行为和部署在Linux还是Windows环境无关。

解决方案 #

方案1：优先使用DateTimeOffset（推荐）

DateTimeOffset会同时存储时间值和对应的时区偏移量，完全规避Kind属性带来的歧义，是处理跨时区时间的更优选择：

string tz = TZConvert.WindowsToIana("Central Europe Standard Time");
TimeZoneInfo tzi = TZConvert.GetTimeZoneInfo(tz);

// 转换为DateTimeOffset，保留偏移信息
DateTimeOffset currentTimeOffset = TimeZoneInfo.ConvertTime(DateTimeOffset.UtcNow, tzi);

// 如需转回DateTime，可根据需求选择：
DateTime asLocal = currentTimeOffset.LocalDateTime; // Kind = DateTimeKind.Local
DateTime asUtc = currentTimeOffset.UtcDateTime; // Kind = DateTimeKind.Utc
DateTime asUnspecified = currentTimeOffset.DateTime; // Kind = DateTimeKind.Unspecified

方案2：手动指定Kind（仅当明确目标时区与系统本地时区一致时使用）

如果业务必须使用DateTime类型，且确认目标时区就是当前系统的本地时区，可以用DateTime.SpecifyKind手动设置Kind：

string tz = TZConvert.WindowsToIana("Central Europe Standard Time");
TimeZoneInfo tzi = TZConvert.GetTimeZoneInfo(tz);

DateTime currentTime = TimeZoneInfo.ConvertTimeFromUtc(DateTime.UtcNow, tzi);
// 仅当tzi是系统本地时区时，才适合指定为Local
DateTime timeWithKind = DateTime.SpecifyKind(currentTime, DateTimeKind.Local);

注意：如果目标时区不是系统本地时区，强行指定Kind为Local或Utc会导致时间逻辑混乱，不建议这么做。

方案3：使用NodaTime库（复杂时区场景推荐）

如果需要更严谨的时区处理，可引入NodaTime库，它专门解决.NET原生DateTime/DateTimeOffset的时区缺陷：

using NodaTime;

var tzProvider = DateTimeZoneProviders.Tzdb;
DateTimeZone ceTz = tzProvider["Europe/Berlin"]; // 对应Central Europe Standard Time的IANA时区
Instant now = SystemClock.Instance.GetCurrentInstant();
ZonedDateTime zonedTime = now.InZone(ceTz);

// 如需转回.NET类型：
DateTimeOffset dto = zonedTime.ToDateTimeOffset();
DateTime dt = zonedTime.ToDateTimeUnspecified();

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