GMT 或无 GMT

发布于 2024-08-07 23:11:51 字数 235 浏览 6 评论 0原文

这可能是个愚蠢的问题,但无论如何我都会问。

我真的需要在现场实施 GMT 才能在帖子上获得正确的时间戳吗?嗯,我正在建立一个像 Twitter 这样的网站。我的提要工作正常,并显示我需要的时间,就像它显示“发布 11 分钟,昨天发布,5 天前发布..”就像这个网站一样,所以我认为它应该适合每个人,你的想法?或者您认为我需要在其上实施 GMT,您是否推荐或有任何关于它的文章以正确的方式实施它?

抱歉,如果这听起来很愚蠢:O

this might be stupid question, but ill ask anyway.

do i really need to implement gmt on site to get proper timestamp on a post? well im building a site like twitter. my feeds are working fine and showing me the time i need, like it shows "posted 11 minutes, posted yesterday, posted 5 days ago.. " just like this site, so i was thinking it should work for everyone properly, what you think? or do you think i need to implement gmt on it and do you recommand or have any article on it for implementing it proper way?

sorry if this sound stupid :O

如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。

扫码二维码加入Web技术交流群

发布评论

需要 登录 才能够评论, 你可以免费 注册 一个本站的账号。

评论(3

牵你手 2024-08-14 23:11:51

从长远来看,最好始终以 GMT/UTC 存储时间戳,无论用户界面如何呈现。这有两个优点:

  • 在某个时候更改 UI 时,您不需要接触数据,
  • 它提供了清晰的设计指南(就明确的正确/错误决策而言):可以独立审查任何处理时间的特定功能字。处理 UTC 时间戳

至于具体的编程指南:这些很大程度上取决于您要执行的功能。大多数时候,您需要 from-utc 或 to-utc 操作。

In the long term, it is best to store time stamps always in GMT/UTC, no matter how the user interface is rendered. This has two advantages:

  • when changing the UI at some point, you won't need to touch the data
  • it gives a clear design guideline (in terms of a clear right/wrong decision): any specific function dealing with time can be independently reviewed wrt. processing timestamps in UTC

As for specific programming guidelines: these depend very much on the functionality you want to execute. Most of the time, you need either from-utc or to-utc operations.

甜味拾荒者 2024-08-14 23:11:51

这是一个很好的观点,但请考虑以下情况:1 天前建议“昨天”,而对于某些用户来说,当前时间是凌晨 1:05。我想如果您使用 days = hours % 24 而不是 days = datediff(then, now).days,那么它会正常工作。

我认为问题是:您的网站需要有多准确?如果是用于医疗读数,以便有人可以知道他们的药物何时到期,那么是的,您需要正确考虑时区,并给出准确的时间,而不仅仅是“x 前”。不过,如果只是为了“乔两天前打过招呼”,那就没什么大不了的。

It's a good point, but consider the case when 1 day ago suggests "yesterday", and it's currently 1:05am for some user. I suppose if you're using days = hours % 24 rather than days = datediff(then, now).days, then it would work fine.

I think the issue is: how accurate does your site need to be? If it's for medical readings, so someone can know when their medication is due, then yes, you want to account for timezones properly, and give accurate times rather than just "x ago". If it's just for "joe said hi two days ago", though, then it's not a big deal.

情深已缘浅 2024-08-14 23:11:51

当你谈论像小时、分钟和秒这样的时间段时,这甚至与时区没有任何关系。查看创建时的时间戳,然后查看现在的时间戳。做一些减法,瞧!

唯一有点奇怪的时候是当你在几天的范围内时。昨天是指“最后一个午夜之前 24 小时内的某个时间”,还是指“超过 24 小时前”?无论如何,如果您提供的唯一粒度级别是“天”,那么一旦过去了大约 2 天,那么它就不再重要了。

避免混淆的一种好方法是在 SO 上使用相同的方法:将可读的、友好的日期放在屏幕上(“昨天”),但将准确的时间(GMT 或用户的 TZ)作为工具提示。

When you're talking about time periods like hours, minutes and seconds, then that's not even anything to do with timezones. Look at the timestamp of when it was created, and look at the timestamp now. Do some subtraction and voila!

The only time it's slightly strange is when you are in the range of a couple of days. Does yesterday mean "some time in the 24 hours prior to the last midnight", or does it mean "over 24 hours ago"? In any case, if the only level of granularity you are providing is "days", then once it's gone past about 2 days, then it doesn't really matter.

One nice way to avoid confusion is the same method used here on SO: put the readable, friendly date on the screen ("yesterday"), but put the exact time (in GMT or in the user's TZ) as a tooltip.

~没有更多了~
我们使用 Cookies 和其他技术来定制您的体验包括您的登录状态等。通过阅读我们的 隐私政策 了解更多相关信息。 单击 接受 或继续使用网站,即表示您同意使用 Cookies 和您的相关数据。
原文