Xinhao Luo

这个路由是一个子集的一部分，处理一下冲突可以合并

~~请提供部署环境信息~~ ~~demo的话，服务器时区默认也不是Shanghai，默认应该使用了北美地区~~ 噢意识到了，这个问题可能需要规范路由写法以后才能解决，目前部分时间使用了自己处理的方式，没有遵守统一的格式处理

> > ~请提供部署环境信息~ > > ~demo的话，服务器时区默认也不是Shanghai，默认应该使用了北美地区~ > > 噢意识到了，这个问题可能需要规范路由写法以后才能解决，目前部分时间使用了自己处理的方式，没有遵守统一的格式处理 > > 奇怪之前没有这个问题，是最近几个路由都同时发生问题 服务换了，时区也变了 但是无论怎么样这个问题都不应该是这样的emmm

#7181 这里是什么问题？ 是不是相关util没有包含文档，我看了一下确实似乎是没有 @queensferryme

> 我了解的情况就在上面评论里了，超话这个路由的问题应该不是时区问题，猜测是date这个工具类处理原始字符串的时候没有匹配上，导致丢失了日期，把所有日期设置成了当天。 > https://rsshub.app/weibo/super_index/1008084989d223732bf6f02f75ea30efad58a9 > 访问这个链接的第一条微博日期是`Sat, 13 Mar 2021 15:37:00 GMT`，而打开链接可以看到发布日期是2月15日 23:37 ，只有37分这个是对的，23时是因为时区，而日期就是完全不对。 > 因此我在我提交的代码里把这个date方法去掉了，也没有+8，自己处理了这个时区 问题是大部分自己处理的情况是不正确的，会受到服务器时区，访问方式变化等影响。这也是为什么我们引入了这个工具集。所有的pubDate应该通过这个方式标识获取的时间以及处理方式。 这个部分文档是缺失的，我也没有时间去处理，所以在让目前正在处理的贡献者提供建议

@queensferryme cc @DIYgod 可以的话直接改把，然后写一下文档。 我觉得我们可以接受一个dayjs object，或者是date object。这样我们可以拿到一个带时区的时间，然后再统一按照需求转换 再这个问题解决之前我们先暂缓新路由添加

@queensferryme 这样子的话，因为我们大多数情况下还是要做一次string2object 两个参数的情况作为fallback保留 新增接受一个参数的使用方式，传入必须是dayjs或者date object然后接续处理 cc @SukkaW 看看有没有更好的处理方法

@tuzi3040 现在主要问题是在于pubdate传入的部分可能太多，同时可能需要按照客户/服务器时区进行调整，需要规范一下 方法1，通过要求使用指定工具类 方法2，验证ctx pubdate是否符合规范，在届时统一处理 方法2的问题是如果采用object的方式，目前大部分缓存直接将object塞进去会是一个问题

> @NeverBehave @tuzi3040 > > 我们可以只指定时区名称，字符串总是可以被序列化、作为 cache key 的吧。 > > 大概几个可能会用到的 Code Snippet： > > ```js > // 获取当前 JS Runtime（即 RSSHub 服务端）当前时区，Node.js 8.10.0 起提供完整支持 > Intl.DateTimeFormat().resolvedOptions().timeZone; > ```...

由于部分路由需要继续追踪相关问题，重新开启 请后续pr不要带close标签，仅关联issue