求助一个有关 nest.js 中与 Nodejs 相关的问题。
我使用 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’.
要么一种就是在服务层对取出的数据在转化一下。
想要问一下,实体类中有没有办法对取出的数据进行转化。
求助一个有关 nest.js 中与 Nodejs 相关的问题。
需要转什么?
timestamp 发到前端你 new Date(timestamp) 直接用就好了呀
你变量的数据类型是 String 吧?改成 Date 就行了
转换后的时间是没有时区,非 +8 时区用户会看到不正确的时间
应该前端接收 iso 、时间戳,js 转换时间
显示啥样这不就该是前端的活吗
发给前端的格式不一样,还需要转一下。所以我想直接在后端进行转化了。类似 java 里面的 (pattern = “yyyy-MM-dd HH:mm:ss”, timezone = “GMT+8”)这样的注解
是 Date 的,但是存入数据库后取出来是 2023-08-27T21:55:45.000Z"这样的,我希望是 2021-08-31 07:56:10 这样。希望在实体类中就能转化掉。java 中有 (pattern = “yyyy-MM-dd HH:mm:ss”, timezone = “GMT+8”)的注解,我想知道 typeorm 里面有没有类似的注解
你直接发 timestamp 有什么问题?
如果你怕直接发 Date 对象不好 serialize,那你+Date 一下发 int64 呗,为啥要费那老劲弄一长串字符串
发原始时间给前端,前端有很多库,转更灵活一些
你那前端不会自己用 new Date(timestamp) 和 data.toLocalString() 方法吗…那你就服务端用这两个方法转了给他呗
typescript<br>()<br>((d) => moment(d.value).toDate().getTime())<br>createTime: Date;<br>
我是把 date 转为 timestamp ,用了 moment ,你根据自己需求改就好

这个是什么插件?
大佬们太强了
不想要 iso 格式,可以在 app.module 注册 typeorm 时,dateStrings 设置为 true
https://typeorm.io/data-source-options#mysql–mariadb-data-source-options
这种可以让前端去做的事,就不应该消耗服务器资源
后端又不知道浏览器时区,你要怎么序列化?
前后端交互时间戳就好了,你不知道访问的用户是什么时区,后端转太麻烦
说的在 entity 里转是对的。但是你要这样去用来转时间的逻辑是错的。所有的时间交互都应该带时区或者用时间戳,无论是入口还是出口,显示端根据自身时区去做格式化展示。而你这样直接服务端处理了,就相当于前端页面在全球都是展示你服务器时区的时间,明显是有问题,当然,只考虑自己时区无所谓,也不会拓展的话,但是终归是不标准。
建议早日弃坑 TypeORM
哪个好用呢? prisma 还是 mikro?
哥你这方法可行,方便快捷
我这是小项目,如果纯国内的项目其实涉及不到时区吧。不知道大家平时后端对于需要创建日期,更新日期存什么?时间戳么?求问,我入门不太了解这个规范。我看公司的项目好像也是日期。
受教 我这个服务器是在海外 也主要是给海外用户看的 而运营是在国内 所以在后台添加文章的时间要和页面展示的时间一致 我这里就只考虑自己的时区了
其实你小项目也涉及到时区,只是估计你部署的服务器默认给你的是亚洲上海时区而已,然后你前端也是东八区,自然就刚好对上。如果你服务迁移服务器或者用 docker 容器部署,你服务有可能就基于 0 时区上,那你前端展示的时间就会少 8 个小时。这就是隐患。
至于方案,用标准时间包去做时间处理就好了,其实就是带着时区的时间去做交互和转换,这样谁都知道这个时间是表示哪个时间点,至于字符串格式的时间 2023-01-01 00:00:00 ,在于 24 个时区就有 24 个不同的时间。所以,如果是后端的活是不要推给客户端,但是该是客户端的活,也不要揽下来,各自负责各自的责任。前端业务要显示 YYYY-MM-DD 或者 DD/MM/YYYY 格式,那就让前端自己用时间处理包搞,后端负责返回标准时间格式就行。
再说下时间戳,可以理解为 0 时区的 UTC 时间,但是我一般不用,放数据库里不直观,查个数据还得转换一下才能理解。
感觉你可能迷惑的点是存在数据库里的时间字段,其实数据库也是有时区的,你设置了 datetime 格式的字段,显示的是 2023-01-01 00:00:00 这样的格式,如果你数据库设置了 0 时区,那你就在理解上加 8 小时就好,如果是东八区,那就跟我们北京时间一致。
你服务端用 UTC 格式的时间去存数据库,数据库自己会根据自己时区去转换好时间存进去,显示的是数据库时区的时间。我没具体去测过这块,你可以试一下,给数据库不断换时区,看下是不是这样的表现形式。
感谢详细的回复。目前我按照上面一个兄弟说的在 typeorm 上设置 dateStrings 将时间字符串化了,这样取出数据的时候,时间是正常的。2023-08-30 12:22:22 。之前那个是"2023-08-27T21:55:45.000Z"返回给前端还需要在他们转一层。至于前端还需要再转那就前端自己来了。另外你说的时区,我数据库确实也如你说的少了 8 个小时,后来我设置数据库的时区为上海解决了。目前先这样吧。小项目暂时没有考虑到很多。
当然,我很乐意帮你解决关于 Nest.js 和 Node.js 的问题。Nest.js 是一个用于构建高效、可靠和可扩展的服务器端应用程序的框架,它基于 Node.js。
首先,确保你已经安装了 Nest.js 和 Node.js。如果还没有安装,你可以通过以下命令安装 Nest CLI(Nest 的命令行界面工具):
npm i -g @nestjs/cli
安装完成后,你可以创建一个新的 Nest.js 项目:
nest new project-name
进入项目目录:
cd project-name
启动开发服务器:
npm run start
如果你有一个具体的问题,比如如何在 Nest.js 中使用 Node.js 的内置模块,这里是一个简单的例子,展示如何在 Nest.js 控制器中使用 fs
模块读取文件:
首先,导入 fs
模块:
import { Controller, Get } from '@nestjs/common';
import * as fs from 'fs';
@Controller('files')
export class FilesController {
@Get('read')
readFile(): string {
return fs.readFileSync('path/to/your/file.txt', 'utf8');
}
}
在这个例子中,我们创建了一个名为 FilesController
的控制器,并在其中定义了一个 GET 端点 /files/read
,该端点读取并返回指定文件的内容。
如果你有具体的问题或需要更详细的解释,请告诉我!