求助一个有关 nest.js 中的问题。

[qq309187341]

我使用 nest.js+typeorm 进行后端开发。我在实体类中定义了一个创建时间
@Column({ type: "timestamp", default: () => "CURRENT_TIMESTAMP", unique: true })
然后取出数据的时候，格式是日期形式的"create_time": "2023-08-27T21:55:45.000Z",
这个格式，前端接收了需要再转一下。才能变成 '2021-08-31 07:56:10'.
要么一种就是在服务层对取出的数据在转化一下。
想要问一下，实体类中有没有办法对取出的数据进行转化。

[fengYH8080]

@YEX1024 说的在 entity 里转是对的。但是你要这样去用来转时间的逻辑是错的。所有的时间交互都应该带时区或者用时间戳，无论是入口还是出口，显示端根据自身时区去做格式化展示。而你这样直接服务端处理了，就相当于前端页面在全球都是展示你服务器时区的时间，明显是有问题，当然，只考虑自己时区无所谓，也不会拓展的话，但是终归是不标准。

[Zchary]

建议早日弃坑 TypeORM

[LandCruiser]

@Zchary 哪个好用呢? prisma 还是 mikro?

[qq309187341]

@zzh2036 哥你这方法可行，方便快捷

[qq309187341]

@fengYH8080 我这是小项目，如果纯国内的项目其实涉及不到时区吧。不知道大家平时后端对于需要创建日期，更新日期存什么？时间戳么？求问，我入门不太了解这个规范。我看公司的项目好像也是日期。

[YEX1024]

@fengYH8080 受教 我这个服务器是在海外 也主要是给海外用户看的 而运营是在国内 所以在后台添加文章的时间要和页面展示的时间一致 我这里就只考虑自己的时区了

[fengYH8080]

@qq309187341 其实你小项目也涉及到时区，只是估计你部署的服务器默认给你的是亚洲上海时区而已，然后你前端也是东八区，自然就刚好对上。如果你服务迁移服务器或者用 docker 容器部署，你服务有可能就基于 0 时区上，那你前端展示的时间就会少 8 个小时。这就是隐患。
至于方案，用标准时间包去做时间处理就好了，其实就是带着时区的时间去做交互和转换，这样谁都知道这个时间是表示哪个时间点，至于字符串格式的时间 2023-01-01 00:00:00 ，在于 24 个时区就有 24 个不同的时间。所以，如果是后端的活是不要推给客户端，但是该是客户端的活，也不要揽下来，各自负责各自的责任。前端业务要显示 YYYY-MM-DD 或者 DD/MM/YYYY 格式，那就让前端自己用时间处理包搞，后端负责返回标准时间格式就行。
再说下时间戳，可以理解为 0 时区的 UTC 时间，但是我一般不用，放数据库里不直观，查个数据还得转换一下才能理解。

[fengYH8080]

@qq309187341 感觉你可能迷惑的点是存在数据库里的时间字段，其实数据库也是有时区的，你设置了 datetime 格式的字段，显示的是 2023-01-01 00:00:00 这样的格式，如果你数据库设置了 0 时区，那你就在理解上加 8 小时就好，如果是东八区，那就跟我们北京时间一致。
你服务端用 UTC 格式的时间去存数据库，数据库自己会根据自己时区去转换好时间存进去，显示的是数据库时区的时间。我没具体去测过这块，你可以试一下，给数据库不断换时区，看下是不是这样的表现形式。

[qq309187341]

@fengYH8080 感谢详细的回复。目前我按照上面一个兄弟说的在 typeorm 上设置 dateStrings 将时间字符串化了，这样取出数据的时候，时间是正常的。2023-08-30 12:22:22 。之前那个是"2023-08-27T21:55:45.000Z"返回给前端还需要在他们转一层。至于前端还需要再转那就前端自己来了。另外你说的时区，我数据库确实也如你说的少了 8 个小时，后来我设置数据库的时区为上海解决了。目前先这样吧。小项目暂时没有考虑到很多。