质疑“刚刚”“几分钟前”“一天前”“333 天前”等时间戳的先进性

[zpvip]

不知道什么时候吹起了这阵妖风，好多网页的时间全变成了更 “人性化” 的 “刚刚”，“几分钟前”，“一天前”，“35 天前”，但我觉得这并没有更“人性化”，相对 280 天前的时间戳，我更希望知道那天是去年 6 月末。如果是一天内的时间，我知道几点就可以了，没有人回想早餐的时候用 185 分钟前来表述，而是说早上 7 点半。

个人觉得这些“人性化”只不过是一种标新立异，哗众取宠，根本没有必要。微信里发截图本来就是一种毒瘤般的存在，标题下的 “45 分钟前” 让人更加抓狂。

如果你是网页工作者，可以考虑在后台加一个开关，让用户可以选择时间的显示方式。有的网站在点击这种“时间戳”后会显示年月日时分秒，也是一种变通方式，但还是不如一个开关完美。

在座的各位也有相似的体验吗？

[iConnect]

这个问题主要在意这 2 个问题：

1 社交 APP 界面空间小，有些仅标记 1h 这 2 个字符来表示一小时前，完整时间戳得要一条横向空间。

2 另外就是全球性的应用，用户没法算清时差，就算你提供了时区标识，正向 /反向加减时区，有几个人搞清楚了？

[xnotepad]

@em70 我目前看到的都是基于本地计算的。github 也是。

[x66]

同意，建议 站长优化

[yngby]

同意

[IMCA1024]

赞同 LZ 。。
我也比较喜欢准确点的

[vipppppp]

我觉得 lz 的建议挺好的，有一个开关设置
实际上这种几分钟前的描述，我爸妈倒是挺喜欢的...那种新鲜出炉的感觉

[hfutzj]

附议

[SkyCity4NJ]

微信感同身受

[Samuel021]

产品狗举手发言🙋‍♂️

之所以这样用来展示时间主要是有 2 个目的，第一个目的是从技术层面开展的，即“不同国家所能够展示的时间格式不一样，如果用一样的标准去控制，则可能在展示上面出一些小问题”，比如下图


第二个原因是在社交产品中，用“几秒前”，“55 秒前”，“2 分钟前”之类的时间展示方式更容易降低用户之间的距离感，，同时可以传达“这个网站刚刚更新 or 经常这样做的感觉”。个人认为这种逻辑的来源是微博 orTwitter 之类的社交网站，毕竟对于“具备社交属性”的产品来说，内容的新鲜度高低是十分重要的，比如下图


当然了，如果作为后台产品或者工具产品来说，这个功能就需要产品经理来进行对应的把握了，同时产品也需要考虑合理的时间展示对应规则（什么时候是几秒前，什么时候是具体的秒数等等），才能够对研发和用户提供更好的体验。

（给博客打个广告 https://hiwannz.com ）

[jon]

lz
说出了心声啊

[SLink]

显示没有利弊，要放入场景看待。在一天甚至一周的周期内，完全可以使用 xx 分前，xx 小时前，x 天前这类显示；超过某个时间段比如一周后的，因后续查看归档的需要，则可恢复为完整的日期时间显示。很多情况下其实是人在偷懒。个人看法。

[lepig]

楼主说的 我是同意的。 我更倾向于知道哪年哪月哪天，而不是 280 天前。

[kumastudio]

这要看场景了，新闻列表页面我觉得用刚刚、几分钟前，没什么问题，详情页就应该将完整的时间展示给用户。

[Bluecoda]

没有最优解，显示全时间给用户感觉冷冰冰，但是清晰，显示 time ago 会显得人性化很多，但是不那么清晰。主要看应用场景，没必要知道确切时间的地方，可以用 time ago 去显示

[DOLLOR]

“几分钟前”的页面截图之后，过几年再炒旧饭不容易被揭穿，比较适合靠流量吃饭的平台。😅

[yinzhili]

这种设计我个人觉得也是很烦且毫无意义的。
假如有人对页面截了图，里面看到的时间是“5 分钟前”，那其他人拿到这张图根本无法知道确切的时间是什么。

[unknowfly]

突然想起 docker 查看容器信息也是这样子

[devcat]

同意楼主的观点

[RuiQ]

gitlab 翻记录的时候简直要逼疯人 对不上时间点 气死我了

[no1xsyzy]

（下例假定现在时间 2020-02-02T10:33:00 ）
想象一下一个设计上应该每 10 分钟触发一次的定时任务，那么 “上次触发：13 分钟前” 比 “上次触发：2020-02-02 10:20:00” 自然更明显地显示了这个任务没有被正确地再次触发。
想象一下一个设计上每天随机某个时刻触发的定时任务，那么 “上次触发：前天 23:59” 比 “上次触发：34 小时前” 或者 “2020-01-31 23:59” 更明显地显示了这个任务没有被正确地触发（注意！这边混杂了 “相对时间段” 和 “绝对时间点”）

另一方面，公众意义的界面更需要绝对时间，而采用色调来区分新鲜度、色块的不透明度区分热度。
只要咕咕病不发作，周末写个 userscript 试试（

[lostaya]

我比较喜欢几分钟前这种设定。一眼就能判断这个帖子有无回复，如果是时间戳可能还要看一下现在几点，如果沉浸在摸鱼看帖里忘了的话。

[ooops]

主要是这个 xx 前是没有标准的，想做成什么样，所以什么奇葩的显示效果都有。
253 天前，没人知道那是去年的哪天。
150 分钟前， 还得算是几个小时。
8 天前，是周几？
如果鼠标或者点击时可以显示具体时间的话，体验还是可以的了。
做过一个需求是要求：15 分钟以内是 刚刚，15 分-1 小时 显示 xx 分钟前，1-24 小时 显示 xx 小时前，1-7 天显示 xx 天前，今年显示 MM-dd hh:mm，跨年显示 yy-mm-dd hh:mm 。没人能理解到这个刚刚是有多刚。
当前这个也不能一刀切。全显示成具体的时间点也有人闹心的。

[yaaaaaak]

x 分钟前不是特别适合造谣用嘛。隔一段时间放一次出来

[huhexian]

https://pewae.com/ 这个博客文章页里的评论，时间戳是发文 XX 小时之后，挺有特色，时间久的会显示发文 xx 年后

[efaun]

@Samuel021 #109 第一条，技术层面的问题都不是问题，人才是问题，第二条，所以推出一个功能的时候，一定要做好灰度测试，这就是为什么张小龙被那么多人骂

[wtf12138]

没看见这个问题之前，一直没觉得 XX 天前有什么使用障碍，说明这就是为我这种人设计的 233333

[yuuko]

同意，这种真的滥用了

[xingheng]

对于爬虫而言，标准时间格式自然最好。对于用户而言，我觉得这种“人性化”也没什么不好。从设计角度上讲，用这种时间表示法也是一种弱化精准时间的方法。

[hsddszjs]

我十分同意楼主

[sardine]

我感觉在游戏里用谁谁几分钟前、几小时前、几天前上线很实用，微信里用这种格式就很鸡肋

[Samuel021]

@efaun #125 您说的对，我的两条也是从经验中得出的。

也有研发会偷懒，遇到时间显示的问题直接问产品怎么办，或者就直接强制按照 GMT 去显示了；
而对于微信这种体量的产品来说，其实灰度这一步更多是看遇到的错误自己能否接受，比如朋友圈评论功能上线了之后发现无法监管，所以就下线了，而这种 timestamp 展示格式的东西，我更倾向于是从 twitter 中复用的概念了（不过我也没有验证哈哈哈哈）

[CommandZi]

@iConnect 说说看 Telegram ？

[py2ex]

@Samuel021 #109 相比微博这些社交软件，v2ex 更加注重沉淀。
参考“请尽量让自己的回复能够对别人有帮助”这个提示，和很多人在搜索结果中看到了发表在过去但仍然有用的文章而了解到 V2EX 这个网站这个现象。

[zjj19950716]

long long ago

[dreamage]

最烦看到 1 天前，并不知道是 [几小时,48 小时)

[Infinite2K]

非常同意，每次看到 xxx 天前，我都会算一下究竟是哪一年哪个月哪一天，着实麻烦。
但如果像那种很久之前的，标注 xxxx 年 xx 月 xx 日，我会一目了然。

我不在意是多少天前，因为这对我没意义，但我在意几月几日。

[Oosl]

同意，第一感觉这样不行，就是 win10 文件管理 下载里面搞了个分类，发现完全不直观

[acess]

@iConnect 不需要用户加减时区吧，服务器保存 UTC 时间，到用户这里自动换算成本地时间不就 OK 了。如果都显示各自的本地时间，那岂不是全乱了，分不清先后了。

[acess]

@iConnect 补充一下，换算成用户本人的本地时间，而不是其他人的本地时间。

[ligong]

附议，我最近被这个东西逼疯了，我需要确切的时间信息做总结啊。