You need to enable JavaScript to run this app.
优惠活动
大模型
产品
解决方案
定价
更多

C# API与TypeScript间日期时间传输问题求助

解决前端TypeScript Date与后端DateTimeOffset时区传输问题

核心问题分析

前端Date对象在JSON序列化时会被转换为UTC时区的ISO8601字符串(如2023-12-11T07:49:00Z),而非控制台显示的带+01:00偏移的时间。后端解析这个UTC字符串时,会生成对应UTC时间的DateTimeOffset,导致最终时间比预期的柏林时间早1小时。

解决方案

1. 前端修改数据类型与转换逻辑

放弃使用Date类型传输日期,直接传递带时区偏移的ISO8601字符串,确保时区信息完整保留:

  • 更新Setting接口:
export interface Setting {
    validFrom?: string; // 改为string类型,存储带时区的ISO字符串
    validTo?: string;
}
  • 调整parseDateForSave方法,返回带时区的ISO字符串而非Date对象:
const parseDateForSave = (dateString?: string) => {
    if (!dateString) return undefined;
    // 将用户输入的柏林时区时间转换为带时区偏移的ISO8601字符串
    return moment.tz(dateString, "YYYY-MM-DDTHH:mm", "Europe/Berlin").format();
};

注:moment.format()默认返回带时区偏移的ISO格式(如2023-12-11T08:49:00+01:00),完全符合后端DateTimeOffset的解析要求。

  • formatDateForDisplay方法可保持不变,用于将后端返回的DateTimeOffset字符串(或前端存储的字符串)转换为datetime-local所需的格式。

2. 后端无需修改类型

ASP.NET Core默认的System.Text.Json序列化器能够正确解析带时区偏移的ISO8601字符串,并映射到DateTimeOffset类型,因此后端的Setting类和接口无需调整。

3. LastUpdate字段处理

  • 如果LastUpdate是前端传入的,按照上述前端逻辑传递带时区的ISO字符串即可。
  • 如果是后端生成的,继续使用DateTimeOffset.Now,它会自动包含服务器所在时区的偏移信息,写入数据库时能保持正确时间。

验证

修改后,前端传递的JSON数据中validFrom/validTo会是类似"2023-12-11T08:49:00+01:00"的字符串,后端解析为DateTimeOffset时会保留+01:00的偏移,与预期时间一致。

内容的提问来源于stack exchange,提问作者TheDentist

相关产品推荐
方舟 Agent Plan

超全模态模型 × Harness 升级,最新支持 Deepseek-V4.1-Flash、GLM-5.3 系列、Doubao-Seedream-5.0-pro、Kimi-K3 (部分), 限时 9.9 元起

最近更新时间:2026.07.03 23:30:04