JavaScript与C#之间传输日期时间的更优实现方案咨询

现有方案的可优化点 #

你当前的实现逻辑是可运行的，但存在两个可优化的点：

• 手动硬编码Unix纪元起始时间（1970-01-01 UTC）的写法没有必要，.NET已经提供了原生的转换方法，可读性和可靠性更高
• 末尾强制调用ToLocalTime()会依赖服务器所在的时区配置，如果应用跨区域部署、或者面向跨时区用户，很容易出现时间偏移问题，更推荐优先保存/使用UTC时间，在前端展示时再转换为用户本地时区时间

方案1：使用.NET内置转换方法替代自定义逻辑 #

.NET Framework 4.6、.NET Core 1.0及以上版本，已经内置了DateTimeOffset.FromUnixTimeMilliseconds方法，不需要自己实现转换逻辑：

// 转换为UTC时间的DateTime，推荐优先用这个
public static DateTime GetUtcDateFromMilliseconds(double unixTimeStamp)
{
    return DateTimeOffset.FromUnixTimeMilliseconds((long)unixTimeStamp).UtcDateTime;
}

// 如果你确实需要获取服务器本地时间，用这个替代原实现更规范
public static DateTime GetLocalDateFromMilliseconds(double unixTimeStamp)
{
    return DateTimeOffset.FromUnixTimeMilliseconds((long)unixTimeStamp).LocalDateTime;
}

这个原生方法经过官方测试，不会出现手动配置纪元时间的参数错误，性能和自定义实现几乎一致，维护成本更低。

方案2：改用ISO 8601格式传输（更推荐） #

如果不限制必须用时间戳传输，更推荐前后端用ISO 8601格式的字符串传递日期：

• 前端不用调用getTime()，直接调用Date.toISOString()即可输出类似2024-06-15T09:30:45.123Z的标准格式字符串
• 基于ASP.NET/ASP.NET Core开发的API可以直接将这个格式的字符串自动绑定到DateTime/DateTimeOffset类型的接口参数，完全不需要写任何转换代码
• 传输内容可读性更高，调试接口时不需要手动转换时间戳排查问题，也完全避免了两端时区处理不一致、精度损失的问题，是目前行业内的主流实践。

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