1. 为什么我们需要更高精度的时间戳？
记得去年我参与一个金融交易系统开发时，遇到一个头疼的问题：两个几乎同时发生的交易，在日志里显示的时间戳完全一样。这导致排查问题时根本分不清先后顺序，团队花了整整两天才理清这个bug。这就是典型的时间戳精度不足引发的问题。
传统的时间戳通常只精确到秒或毫秒级别，但在现代分布式系统中，这已经远远不够了。比如：
- 高频交易系统需要精确到微秒甚至纳秒
- 物联网设备采集的数据可能每秒产生上千条记录
- 分布式系统的事件排序需要非常精确的时间参考
在C#中，DateTime的默认精度是100纳秒（即1个tick），但很多开发者并不知道如何充分利用这个特性。更麻烦的是，当数据需要在不同系统间传递时——比如前端用JavaScript，后端用C#，数据库又用PostgreSQL——时间戳的转换经常会出现微妙的精度丢失问题。
2. C#中的高精度时间处理实战
2.1 获取微秒级时间戳
.NET提供了Stopwatch类可以获取高精度时间，但直接用它生成时间戳并不方便。我推荐使用DateTime的Ticks属性：
public static long GetMicrosecondTimestamp() { DateTime epoch = new DateTime(1970, 1, 1, 0, 0, 0, DateTimeKind.Utc); TimeSpan elapsed = DateTime.UtcNow - epoch; return elapsed.Ticks / (TimeSpan.TicksPerMillisecond / 1000); }这个方法返回的是从Unix纪元开始的微秒数。为什么用Ticks？因为：
- 1 Tick = 100纳秒
- 1微秒 = 10 Ticks
- 这样计算可以避免浮点数运算带来的精度问题
2.2 处理纳秒级精度
对于需要纳秒级精度的场景（比如科学计算），我们可以这样扩展：
public static (long seconds, long nanoseconds) GetNanosecondTimestamp() { DateTime epoch = new DateTime(1970, 1, 1, 0, 0, 0, DateTimeKind.Utc); TimeSpan elapsed = DateTime.UtcNow - epoch; long ticks = elapsed.Ticks; return (ticks / TimeSpan.TicksPerSecond, (ticks % TimeSpan.TicksPerSecond) * 100); }这里返回一个元组，包含完整的秒数和剩余的纳秒数。注意.NET本身不支持纳秒级时间获取，这个方案实际上是把ticks换算成了纳秒。
3. 跨系统时间戳交换的坑与解决方案
3.1 JavaScript与C#的时间戳互转
前后端分离架构中最常见的问题就是时间戳格式不匹配。JavaScript的Date.getTime()返回毫秒数，而C#可能使用ticks或微秒。
这是我常用的转换方法：
// C#接收JS时间戳 public static DateTime FromJsTimestamp(long jsTimestamp) { return new DateTime(1970, 1, 1, 0, 0, 0, DateTimeKind.Utc) .AddMilliseconds(jsTimestamp); } // C#生成JS兼容的时间戳 public static long ToJsTimestamp(DateTime dateTime) { return (long)(dateTime.ToUniversalTime() - new DateTime(1970, 1, 1, 0, 0, 0, DateTimeKind.Utc)) .TotalMilliseconds; }3.2 数据库存储的最佳实践
不同数据库对时间精度的支持差异很大：
| 数据库 | 最高精度 | 推荐存储格式 |
|---|---|---|
| SQL Server | 100纳秒 | datetime2 |
| PostgreSQL | 微秒 | timestamp |
| MySQL | 微秒 | datetime(6) |
| SQLite | 毫秒 | TEXT(ISO8601) |
在C#中与数据库交互时，我强烈建议始终使用UTC时间：
// 保存到数据库 var parameter = new SqlParameter("@created", SqlDbType.DateTime2) { Value = DateTime.UtcNow, Precision = 7 // 最大精度 }; // 从数据库读取 DateTime dbTime = reader.GetDateTime(0).SpecifyKind(DateTimeKind.Utc);4. 时区处理的正确姿势
4.1 时区转换的常见错误
我见过最典型的错误是这样的代码：
// 错误示例！ DateTime utcTime = DateTime.UtcNow; DateTime localTime = utcTime.ToLocalTime(); string savedTime = localTime.ToString("o"); // 存储到数据库问题出在哪？这个localTime丢失了时区信息！当其他时区的用户读取这个数据时，会得到错误的时间。
4.2 推荐的时区处理方法
正确的做法是始终存储UTC时间，只在显示时转换：
// 存储 DateTime utcTime = DateTime.UtcNow; SaveToDatabase(utcTime); // 显示 DateTime storedTime = GetFromDatabase(); TimeZoneInfo userTimeZone = TimeZoneInfo.FindSystemTimeZoneById("Asia/Shanghai"); DateTime userLocalTime = TimeZoneInfo.ConvertTimeFromUtc(storedTime, userTimeZone);对于需要支持多时区的系统，我建议在用户配置中保存时区ID（如"America/New_York"），而不是时区偏移量，因为偏移量不考虑夏令时。
5. 实战中的性能优化
处理高精度时间戳时，性能往往成为瓶颈。经过多次测试，我总结了几个优化点：
避免频繁的DateTime.Now调用：这个调用比DateTime.UtcNow慢约3倍。如果不需要本地时间，始终使用UtcNow。
预计算基准时间：
// 静态初始化，避免重复计算 private static readonly DateTime Epoch = new DateTime(1970, 1, 1, 0, 0, 0, DateTimeKind.Utc); public static long OptimizedTimestamp() { return (long)(DateTime.UtcNow - Epoch).TotalMilliseconds; }- 批量操作时使用单一时间基准：
DateTime batchTime = DateTime.UtcNow; foreach(var item in items) { item.Timestamp = batchTime; // 而不是每次都获取新时间 }在最近的性能测试中，这些优化让时间戳相关操作的吞吐量提升了近5倍。
6. 日志系统中的时间戳实践
在分布式日志系统中，时间戳的准确性至关重要。我们采用这样的方案：
- 每台服务器启动时校准NTP时间
- 所有日志使用统一的ISO 8601格式：
string logTime = DateTime.UtcNow.ToString("yyyy-MM-ddTHH:mm:ss.ffffffZ");- 在日志中附加机器时区信息
- 使用高精度计时器计算耗时：
var stopwatch = Stopwatch.StartNew(); // 执行操作 stopwatch.Stop(); double microseconds = stopwatch.ElapsedTicks * (1000000.0 / Stopwatch.Frequency);这套方案帮助我们成功将跨服务器日志的时间偏差控制在100微秒以内。
7. 测试中的时间模拟技巧
单元测试中处理时间相关逻辑时，我推荐使用时间抽象：
public interface IClock { DateTime UtcNow { get; } } public class SystemClock : IClock { public DateTime UtcNow => DateTime.UtcNow; } public class TestClock : IClock { public DateTime UtcNow { get; set; } }这样在测试中可以轻松模拟任意时间点：
var clock = new TestClock { UtcNow = new DateTime(2020, 1, 1) }; var service = new TimeCriticalService(clock); // 测试代码这个模式特别适合测试定时任务、缓存过期等时间敏感的逻辑。
)
