在日常的业务开发里日期时间处理看着不起眼却是最容易埋雷的地方之一。无论是用户注册时间、订单创建时间还是统计报表里的时间维度几乎每个系统都绕不开DateTime。很多人觉得自己早就把DateTime用熟了但真到排查线上问题的时候才发现对它的理解还停留在会用几个方法和属性的层面。这篇文章就从 .NET 的DateTime基础类型出发结合实际开发中的使用场景把创建、格式化、比较、时区处理这些核心知识点掰开揉碎讲清楚顺便分享一些我在项目中踩过的坑和总结出来的经验。不管你是刚入门的新手还是写过几年业务代码的老手这篇文章都能帮你把DateTime这块的地基打得再牢一点。1. 内容整体设计与思路拆解1.1 为什么 DateTime 是基础但必须吃透的类型先问一个问题你在写代码的时候真的清楚DateTime是什么吗它不是简单的年月日时分秒而是一个在 .NET 中承载时间语义的值类型。正因为它被设计成值类型所以它在赋值、传参、比较时都遵循值类型的规则这在日常开发中会衍生出一系列不容易察觉的行为差异。举个最常见的例子两个 DateTime 变量进行比较我们用运算符比较的是时刻是否相同而不是显示的字符串是否相同。这一点很多人知道但真到处理不同时区的数据时往往会因为忽略Kind属性而栽跟头。DateTime的Kind属性有三种取值Unspecified、Utc、Local。默认情况下如果你直接new DateTime(2024, 1, 1)它的 Kind 就是Unspecified。这意味着这个时间既不是本地时间也不是 UTC 时间它就是一个抽象的时刻不绑定任何时区。很多开发者在拼接时间参数时根本没留意这个属性导致在后端与前端交互、API 向下游传递时间时出现时间偏差问题。我在一次对接第三方支付接口的时候就吃过这样的亏。对方接口要求的签名时间必须是 UTC 格式的 ISO8601 字符串而我们系统里存的是数据库读出来的 DateTimeKind 通常是Unspecified。直接调用ToString(o)输出的是不带时区偏移的字符串对方解析成 UTC 后时间就差了 8 小时签名一直验证失败。后来排查了很久才发现问题不是出在签名算法上而是出在时间类型的语义没有明确指定。这就是为什么要彻底理解DateTime的原因。它不是能用就行而是要清楚它在什么场景下代表什么语义以及系统边界上的时间传递该如何处理。1.2 从使用场景反推需要掌握的技术点如果你去搜索引擎查DateTime的用法翻来覆去就是那几个属性Now、UtcNow、Today、AddDays、ToString之类的。但实际开发中我们面临的问题远比这些基础用法要复杂需要把用户输入的字符串解析成时间但用户输入的格式可能是多种多样的。需要计算两个时间之间的天数差、月数差但直接相减得到的是TimeSpan天数可能和直观感受对不上。需要把时间格式化成指定格式的字符串给前端展示或者传给别的系统但格式化的坑也不少尤其是在处理 ISO8601 和周数时。需要处理时区问题但DateTime本身不包含时区信息这时候要考虑是否应该用DateTimeOffset。需要对时间进行序列化和反序列化可能在 .NET 的 JSON 序列化中因为默认设置不同得到完全不同的结果。基于这些应用场景我们可以先把DateTime的核心知识点拆成几个模块创建与初始化、格式化与解析、时间运算与比较、时区与会话边界处理、以及序列化和性能考量。下面的章节就沿着这条主线把每个模块的核心细节和实操要点过一遍。2. 核心细节解析与实操要点2.1 DateTime 的创建与初始化远不止 new 一个对象那么简单DateTime now DateTime.Now;这行代码可能是很多人接触DateTime的第一条语句但它只是冰山一角。在实际开发中我们有多种方式创建 DateTime不同方式的语义和应用场景各不相同DateTime.Now获取当前本地时间。它的Kind是Local。在服务器端使用时它依赖服务器的时区设置。如果服务器的时区配置错误那你拿到的所有本地时间都是错的。我见过不少部署在云服务器上的应用服务器时区被设置成了 UTC导致业务日志里记录的时间比用户实际操作时间慢了 8 小时。DateTime.UtcNow获取当前的 UTC 时间Kind是Utc。它不受服务器时区的影响适合用于记录操作时间、日志时间、跨系统传递的时间标准值。DateTime.Today获取当前日期时间部分为 00:00:00Kind为Local。适合做按天统计时的边界条件。new DateTime(year, month, day, hour, minute, second)手动创建时间Kind默认是Unspecified。使用这种方式时一定要根据业务上下文手动指定Kind或改用DateTimeOffset。DateTime.Parse/TryParse从字符串解析时间。DateTime.FromBinary、FromFileTime等从二进制或 Windows 文件时间转换而来用的场景比较少但偶尔会给老接口做兼容时用到。这里有个容易混淆的点DateTime.Now和DateTime.Today在一天内的不同时刻调用结果不同前者带当前时分秒后者始终是零点。我自己在写按时间段查询的接口时为了获取今天零点到当前时间这个区间曾经直接用了DateTime.Today作为开始时间却忽略了后端服务器和数据库服务器时间不一致的问题。如果应用服务器和数据库服务器位于不同时区或者系统时间没有同步那查出来的结果就会含混不清。还有一个隐藏的细节是DateTime.MaxValue和DateTime.MinValue。MinValue是 0001 年 1 月 1 日零点MaxValue是 9999 年 12 月 31 日 23:59:59.9999999。很多 ORM 框架为可空日期字段做默认值时会用到这两个边界值但如果你在业务逻辑里不小心把MinValue当作没有设置传给前端序列化后会变成0001-01-01T00:00:00这种时间在大多数前端组件里是解析不了的轻则显示异常重则导致前端崩溃。所以一般会建议在 DTO 中把这种边界值转成null或空字符串。2.2 格式化与解析字符串和时间之间的桥与坑时间格式化应该是大家平时用得最多的功能了但也正因为常用很多细节容易被忽略。DateTime.ToString(string format)支持自定义格式字符串比如yyyy-MM-dd HH:mm:ss24 小时制日期时间yyyy/MM/dd斜杠分隔的日期HH:mm只显示小时和分钟yyyy-MM-ddTHH:mm:ssISO8601 风格中间用 T 分隔在实际项目中我强烈建议统一时间格式的使用规范。比如数据库统一存datetime2接口返回给前端统一用yyyy-MM-ddTHH:mm:ssISO8601日志里统一用yyyy-MM-dd HH:mm:ss.fffffff带毫秒或百纳秒精度。如果大家的代码里格式字符串满天飞yyyy/MM/dd、dd-MM-yyyy、MM/dd/yyyy混着写后续做日志分析和接口对接时会非常痛苦。格式化的坑主要集中在这几个方面月份和分钟的冲突MM表示月份mm表示分钟大小写不能混。这是新手最容易犯的错误但老手在着急的时候也会不小心搞混。12 小时制与 24 小时制hh是 12 小时制HH是 24 小时制。如果不小心用了hh下午的时间会显示成 01、02 之类用户看了会一头雾水。区域性差异DateTime.ToString()不带格式字符串的时候会使用当前线程的CurrentCulture。在zh-CN环境下默认的短日期格式是yyyy/M/d但在en-US环境下是M/d/yyyy。这就会导致同一个代码在不同环境中运行输出的字符串格式完全不同。所以接口返回时间字符串时要么显式指定格式要么使用CultureInfo.InvariantCulture。ISO8601 格式o格式可以输出带毫秒的 round-trip 格式例如2024-01-15T10:30:00.123456708:00如果 Kind 是 Local或2024-01-15T10:30:00.1234567Z如果 Kind 是 Utc。这个格式适合系统间传递时间因为它是无歧义的。但是如果 DateTime 的 Kind 是Unspecifiedo格式就不会带时区偏移接收方只能自己猜这是什么时区就很容易出问题。解析字符串为 DateTime 时同样有各种细节。使用TryParseExact的时候如果输入的字符串和格式字符串不完全匹配比如多了一个空格、月份是 M 而不是 MM就会解析失败。所以我建议解析用户输入时尽量给出多种期望格式并使用DateTimeStyles.AllowWhiteSpaces。解析来自固定系统内部服务或数据库的字符串时使用TryParseExact加确定的格式字符串避免因区域性差异而解析出错。2.3 时间运算与比较别让 TimeSpan 的直觉坑了你忍不住想强调一下DateTime做加减运算返回的是TimeSpan还是DateTime取决于你用的是什么方法。DateTime.AddDays(double value)、AddHours(double value)这些方法返回DateTime可以链式调用。比如date.AddDays(1).AddHours(-2)表示先加一天再减两小时。注意这些方法的参数是double而不是int所以你可以传小数。比如date.AddDays(0.5)表示加 12 小时。这个设计给了一些灵活的用法但也容易让人忽略精度问题浮点计算的误差可能会让结果带一些非常小的毫秒差异比如明明想得到整天的时间结果却多了一两个 tick。两个 DateTime 直接相减返回的是TimeSpan。比如TimeSpan diff endDate - startDate;TimeSpan有Days、Hours、Minutes、TotalDays、TotalHours等属性。Days是整天数TotalDays是带小数的天数。如果要计算两个日期相差多少天(endDate - startDate).TotalDays会因为时间部分的存在产生小数。比如2024-01-01 08:00:00到2024-01-02 07:00:00TotalDays是 0.9583 天而不是 1 天。如果只想要自然日差值需要先把时间部分归零int days (endDate.Date - startDate.Date).Days;月份差的计算没有现成方法。如果只是用TimeSpan换算成 30 天一个月那肯定不准确。我在做会员有效期计算时需要判断当前时间距离开通时间是否满了一个月网上很多代码就直接用(now - createTime).TotalDays 30来判断这会导致 2 月份开通的用户和 3 月份开通的用户到期时间不一致。正确的做法应该是比较年月分界public static int MonthDifference(DateTime start, DateTime end) { int months (end.Year - start.Year) * 12 (end.Month - start.Month); if (end.Day start.Day) months--; return months; }这里的逻辑是先算整月的差值再根据日期大小做调整。比如2024-01-31到2024-02-29差值是 1 个月但如果不做end.Day start.Day的调整就会算出 2 个月因为年份和月份都变了。这类边界问题在做账单、会员、订阅业务时特别常见务必要测试清楚。再聊一个比较的操作细节。DateTime 支持直接使用比较运算符比如、、、。比较本质上是比较Ticks属性DateTime的Ticks是从0001-01-01起经过的 100 纳秒间隔数。因此DateTime比较是没有时区概念的它比较的只是内部的 ticks 数值。这也意味着如果你有一个当地时间的 DateTime 和一个 UTC 时间的 DateTime直接比较是不合理的。它们虽然刻度都是自 0001-01-01 起算但语义不同直接比较结果可能和预期完全不同。这种情况下要么统一转成DateTimeOffset要么先把两个时间都转到同一个标准比如都转成 UTC ticks再比较。3. 实操过程与核心环节实现3.1 配置时间处理的统一基础设施这里分享一下我在实际项目中搭建时间处理基础组件的思路供你参考。首先要做的是在团队中确定一个标准系统内部所有时间传递服务间调用、数据库读写、Redis 缓存、消息队列默认使用 UTC面向用户展示时再转成本地时区。这个原则一旦确定后续所有代码都围绕这个规范来写可以避免大量的时区混乱。接着在代码层面做好几个基础封装统一时间获取入口虽然DateTime.UtcNow已经是标准做法了但为了可测试性和未来可能的时间源切换建议封装一个IClock接口public interface IClock { DateTime GetCurrentUtcTime(); DateTime GetCurrentLocalTime(TimeZoneInfo timeZone); } public sealed class SystemClock : IClock { public DateTime GetCurrentUtcTime() { return DateTime.UtcNow; } public DateTime GetCurrentLocalTime(TimeZoneInfo timeZone) { return TimeZoneInfo.ConvertTimeFromUtc(DateTime.UtcNow, timeZone); } }这样做的好处有两个一是单元测试时可以传入固定的时间避免测试结果受到当前时间影响二是如果未来要切换到其他时间服务比如 NTP 同步只需要替换实现即可。时间字符串格式的标准化把常用的时间格式定义为常量public static class TimeFormat { public const string ShortDate yyyy-MM-dd; public const string LongDateTime yyyy-MM-dd HH:mm:ss; public const string Iso8601 yyyy-MM-ddTHH:mm:ss.fffZ; public const string LogTimestamp yyyy-MM-dd HH:mm:ss.fffffff; }所有系统间的数据传输统一使用 Iso8601 格式所有日志输出统一使用 LogTimestamp 格式。这样排查日志时时间格式一致用 grep 或日志分析工具就能很方便地过滤出问题时间点。序列化全局设置如果项目中使用 System.Text.Json 或 Newtonsoft.Json建议在全局配置中指定时间格式。以 System.Text.Json 为例var options new JsonSerializerOptions { // 统一用 UTC并且指定 ISO8601 格式 Converters { new IsoDateTimeConverter() }, // ... };当然System.Text.Json中默认就是 ISO8601 格式但对DateTime的 Kind 处理上也有需要注意的地方。默认序列化DateTime时如果 Kind 是Unspecified输出不带时区偏移如果 Kind 是Local输出带本地偏移如果是Utc输出带 Z 后缀。要让序列化结果稳定就必须在源头把时间语义定清楚。3.2 使用 DateTime 处理业务时间的完整流程我们来模拟一个典型的业务场景用户下单需要记录下单时间、计算订单超时时间、并按天统计订单数量。第一步记录下单时间下单时间应该记录 UTC 时间方便后续跨时区分析和展示。在服务端接收到下单请求时DateTime orderTimeUtc DateTime.UtcNow;数据库存储时建议使用datetime2类型并且在连接字符串或 ORM 配置中确保不进行隐式时区转换。EF Core 中默认会以DateTime的原始值写入数据库但要确保写入的时候 Kind 不发生改变。有一些数据库提供程序会擅自转换时区这时需要在OnModelCreating里配置modelBuilder.EntityOrder() .Property(o o.OrderTimeUtc) .HasConversion( v v, v DateTime.SpecifyKind(v, DateTimeKind.Utc));这样可以确保从数据库读出来的时间还保持 UTC 的语义。第二步计算订单超时时间假设订单在 15 分钟内未付款则自动关闭。代码如下DateTime expireTimeUtc orderTimeUtc.AddMinutes(15);由于所有运算都基于 UTC 时间在不同时区的用户看来超时时刻是相同的绝对时间不存在歧义。这里要注意如果有人在代码里用DateTime.Now.AddMinutes(15)去计算那在跨时区环境下就会出现混乱。第三步按天统计订单量按天统计时需要把时间转成目标时区的日期。比如统计中国区的用户订单TimeZoneInfo chinaTz TimeZoneInfo.FindSystemTimeZoneById(China Standard Time); DateTime orderDateInChina TimeZoneInfo.ConvertTimeFromUtc(orderTimeUtc, chinaTz).Date;ConvertTimeFromUtc在大部分平台上支持但要注意 Windows 和 Linux 的时区 ID 可能不同。Windows 上是China Standard TimeLinux/macOS 上可能是Asia/Shanghai。为了跨平台一致性要么封装一个时区查找方法兼容两种 ID要么在部署时明确所用平台并统一时区 ID。这块在容器化部署环境中尤其要注意很多镜像默认时区是 UTC导致TimeZoneInfo.Local不是你预期的时区。在 .NET 6 及以后的版本中TimeZoneInfo.FindSystemTimeZoneById在跨平台上做了一定的兼容但如果真的遇到问题可以先尝试通过 IANA ID 查找如果失败再尝试 Windows ID。3.3 高级场景DateTime 与 DateTimeOffset 的取舍我特意把DateTimeOffset单独拿出来说因为它在现代分布式系统中越来越重要。DateTimeOffset包含一个DateTime和一个Offset偏移量它表示的是一瞬间的时间点同时记录了该时刻相对于 UTC 的偏移。例如2024-06-01T12:00:0008:00表示北京时间中午 12 点而它对应的 UTC 时间是2024-06-01T04:00:00。什么时候该用DateTimeOffset而不是DateTime个人经验是如果时间表示的是一个绝对时刻比如日志时间戳、事件发生时间、消息发送时间优先用DateTimeOffset。如果时间表示的是一个本地时间点比如用户设置的闹钟、每天上午 9 点执行的任务不包含时区信息更适合用DateTime因为闹钟需要的是本地墙上时钟时间而不是绝对时刻。举个例子一个全球化的应用用户在美国纽约设置了一个每天早上 8 点的提醒。如果用DateTimeOffset存储纽约时间的 8 点会随夏令时变化而偏移不同而如果用DateTime存储不考虑时区只是简单的本地每天 8 点语义反而更简单。但这种情况下你需要额外存储用户所在的时区 ID以便在其他时区展示或计算时进行转换。反过来如果是记录用户刚刚下单的时刻用DateTimeOffset更合适。因为它在序列化时自带偏移量接收方可以无歧义地知道这个时刻对应的 UTC 时间且不需要额外约定这个时间是不是 UTC。.NET 中DateTimeOffset可以很方便地和DateTime互转DateTimeOffset dto new DateTimeOffset(dateTime); DateTime dt dto.LocalDateTime; // 转本地时间 DateTime utcDt dto.UtcDateTime; // 转 UTC 时间但注意new DateTimeOffset(dateTime)会根据传入的 DateTime 的 Kind 来推断偏移量如果 Kind 是Utc偏移为 0如果 Kind 是Local偏移为本地时区偏移如果 Kind 是Unspecified会当作本地时间处理这隐含了一种假定可能不太准确容易被忽略。所以在系统间传递时间时我会更倾向于直接使用DateTimeOffset作为 DTO 的字段类型而不是DateTime。反序列化时只要字符串里带着偏移就不用担心时区问题。4. 常见问题与排查技巧实录4.1 时间差了 8 小时到底是哪里出了问题时区问题是开发中遇到最多的一个坑没有之一。我见过太多时间差了 8 小时的案例排查方向无非这几个服务器时区不是预期的时区。执行date命令看看服务器是 CST 还是 UTC。数据库连接中做了时区转换。比如 MySQL 连接字符串里写了serverTimezoneUTC但 Java 驱动可能把它当成了客户端时区导致读写转换。代码中混用了DateTime.Now和DateTime.UtcNow存储到同一个字段里。前端展示时没有做时区转换直接把 UTC 时间字符串当作本地时间渲染。JSON 序列化/反序列化时DateTime的 Kind 信息丢失导致序列化字符串不带时区后缀。我自己有个习惯排查时间问题时第一件事不是去改代码而是先确定这条时间的完整链路上每个环节存的是什么语义的时间。把数据从哪里产生、以什么格式存储、序列化后是什么字符串、前端解析后显示成什么时间这四步全走一遍问题基本就锁定了。如果能输出每个环节的时间字符串配合标准参考时间排查效率会高很多。4.2 DateTime 的可空类型与数据库交互的边界问题数据库中的datetime或datetime2字段可能是NULL对应到 C# 就是DateTime?。在处理可空时间时有几个值得留意的细节读出来的时间Kind 可能是Unspecified因为它不是由 .NET 产生的而是数据库直接返回的。如果需要将其作为 UTC 或本地时间使用必须显式指定 Kind。写入数据库时如果你的 DateTime 的 Kind 是Local一些 ORM 可能会自动转换为数据库本地时间。如果你使用的是云数据库且数据库部署在不同时区就可能导致存储的时间和原意不符。解决办法是规范存储为 UTC 或用DateTimeOffset。查询条件中的时间参数尽量统一用DateTime.UtcNow或DateTimeOffset.UtcNow来生成避免把DateTime.Now直接编进 SQL 参数。4.3 用 Stopwatch 和 DateTime 做性能计时差别很大有些人在代码里用DateTime.Now来做性能统计比如计算某段代码执行了多长时间var start DateTime.Now; // do something var elapsed DateTime.Now - start;这样做有几个问题DateTime.Now的分辨率取决于系统计时器通常在毫秒级别甚至更差而且它受系统时间调整的影响比如 NTP 同步跳变可能导致计时结果出现负值或跳变。正确做法是用System.Diagnostics.Stopwatchvar sw Stopwatch.StartNew(); // do something sw.Stop(); var elapsed sw.Elapsed;Stopwatch基于高精度性能计数器适合测量短时操作。虽然这不是DateTime本身的问题但我发现不少人在做性能测试时会把这两者搞混。4.4 周数和周几的坑拿到的星期对不上号还有一个容易被忽视的场景是周计算。DateTime.DayOfWeek返回的是DayOfWeek枚举它的值是 Sunday0, Monday1, ..., Saturday6。在中国习惯是周一作为一周的第一天但在某些文化中周日才是一周的第一天。如果你要实现本周一、上周五之类的逻辑直接拿DayOfWeek计算结果很可能会出现问题。我一般会这样计算本周一DateTime today DateTime.Today; int daysSinceMonday ((int)today.DayOfWeek 6) % 7; DateTime monday today.AddDays(-daysSinceMonday);这里关键是先做一个映射周一是 0周日是 6然后往前推相应的天数。如果直接today.AddDays(-(int)today.DayOfWeek)在周日那天得到的是上周一而不是本周一。周数的计算第几周更复杂涉及 ISO 8601 定义。.NET 中有Calendar.GetWeekOfYear方法但默认的CalendarWeekRule和FirstDayOfWeek可能不符合中国习惯。如果需要严格的 ISO 周数建议直接使用现成的库代码或者自己实现 ISO 8601 周数算法而不要依赖默认值。4.5 时间格式化的区域性问题如果你在接口返回时间字符串时写的是return dateTime.ToString();这行代码在不同服务器区域设置下会输出完全不同的字符串。比如中文环境是2024/6/1 14:30:00英文环境是6/1/2024 2:30:00 PM。如果前端是用固定格式解析的那必然会出错。所以面向机器的输出API 返回值、文件导出要使用CultureInfo.InvariantCulture或显式格式字符串。面向用户的输出页面展示才需要考虑当前用户的区域设置。内部日志输出建议用固定格式不要依赖机器区域否则日志分析工具处理起来很麻烦。我在项目中曾因为这个问题被坑过一次部署到海外节点的服务日志里时间变成了MM/dd/yyyy格式而国内团队的习惯是yyyy-MM-dd。排查问题时对着两套格式的日志硬生生多花了一个小时。后来定了一个规矩所有日志输出的时间格式统一制定常量不允许直接调用默认 ToString。4.6 序列化 DateTime 时常见的精度丢失DateTime的精度最高到 100 纳秒tick但 JSON 序列化和数据库中存储是有精度上限的JSON 序列化时ISO8601 格式通常保留 3 位毫秒、7 位百纳秒或不保留小数位。不同库的默认行为不同。数据库datetime类型精度约 3 毫秒datetime2可以到 100 纳秒级别。如果从datetime读出来再和代码中精确到 tick 的DateTime.Now做比较它们永远不相等。实际业务中我会尽量避免直接拿两个精度不同的时间做相等比较。比如从数据库读出的订单时间datetime2和缓存在 Redis 中的时间可能序列化后丢失了部分精度如果直接比较大概率不相等。合理的做法是比较某个时间范围内是否包含或者先对时间做统一精度截断再比较。比如只精确到秒DateTime truncated new DateTime(dt.Ticks - (dt.Ticks % TimeSpan.TicksPerSecond), dt.Kind);这类精度问题在数据对账和去重场景中经常出现需要特别注意。4.7 缓存和定时任务中的时间边界定时任务在整点运行时往往需要取上一个整点和当前整点之间的数据。如果直接用DateTime.Now可能会因为秒和毫秒的存在导致边界数据漏掉或重复。比如每 5 分钟执行一次任务查询上次执行到本次执行之间的数据。如果你记录的是DateTime.Now那两次执行的间隔可能不是精确的 5 分钟中间会存在微小的间隙。更稳妥的方案是用DateTime.UtcNow记录执行时间并且将执行时间的精度统一到秒甚至分钟查询时用左闭右开区间 start且 end。缓存过期的时间边界也要注意。很多团队在设置 Redis 缓存 key 的过期时间时直接用DateTime.Now.AddMinutes(10)并且没有明确这个时间是本地时间还是 UTC。如果 Redis 所在服务器和应用服务器时区不一致就可能导致缓存提前或延后过期。统一用 UTC 时间计算过期时间可以规避这类问题。5. 一个实用的 DateTime 操作封装参考聊了这么多最后分享一段我常用的 DateTime 操作封装代码。它不是一个重量级库只是把日常开发中经常用到的逻辑归拢到一起方便复用也方便统一规范。你可以在此基础上针对自己团队的业务场景做裁剪。public static class DateTimeHelper { /// summary /// 获取指定时区当前时间针对服务器时区与业务时区不一致的场景 /// /summary public static DateTime GetNowInTimeZone(string timeZoneId) { TimeZoneInfo tz TimeZoneInfo.FindSystemTimeZoneById(timeZoneId); return TimeZoneInfo.ConvertTimeFromUtc(DateTime.UtcNow, tz); } /// summary /// 格式化为 ISO8601 格式适合系统间传参 /// /summary public static string ToIso8601(DateTime dt) { return dt.ToString(yyyy-MM-ddTHH:mm:ss.fffZ, CultureInfo.InvariantCulture); } /// summary /// 获取两个日期之间的自然日差值忽略时间部分 /// /summary public static int DateDiffDays(DateTime start, DateTime end) { return (end.Date - start.Date).Days; } /// summary /// 获取两个日期之间的整月差值 /// /summary public static int DateDiffMonths(DateTime start, DateTime end) { if (start end) return -DateDiffMonths(end, start); int months (end.Year - start.Year) * 12 (end.Month - start.Month); if (end.Day start.Day) months--; return months; } /// summary /// 获取本周周一周一为一周开始 /// /summary public static DateTime GetMonday(DateTime date) { int daysSinceMonday ((int)date.DayOfWeek 6) % 7; return date.Date.AddDays(-daysSinceMonday); } /// summary /// 将 DateTime 统一转化为 UTC 时间避免 Unspecified 语义导致的问题 /// /summary public static DateTime ToUtc(DateTime dt) { return dt.Kind switch { DateTimeKind.Utc dt, DateTimeKind.Local dt.ToUniversalTime(), _ DateTime.SpecifyKind(dt, DateTimeKind.Utc) }; } /// summary /// 安全解析时间格式列表按优先级依次尝试 /// /summary public static bool TryParseDateTime(string input, out DateTime result, params string[] formats) { if (formats null || formats.Length 0) { return DateTime.TryParse(input, out result); } return DateTime.TryParseExact( input, formats, CultureInfo.InvariantCulture, DateTimeStyles.AllowWhiteSpaces, out result); } }这个辅助类里的方法都不复杂但每个方法背后都对应着一个真实场景。ToUtc方法尤其关键因为在实际代码里从数据库读出来的时间往往是Unspecified如果不显式处理后续所有运算和比较都可能出现偏差。我把这个逻辑封装起来强制走统一入口排查时间问题时事半
