TE
科技回声
首页24小时热榜最新最佳问答展示工作
GitHubTwitter
首页

科技回声

基于 Next.js 构建的科技新闻平台,提供全球科技新闻和讨论内容。

GitHubTwitter

首页

首页最新最佳问答展示工作

资源链接

HackerNews API原版 HackerNewsNext.js

© 2025 科技回声. 版权所有。

Set server timezones to UTC

82 点作者 danlindley将近 9 年前

13 条评论

azdle将近 9 年前
Why not use TAI? You get all the same benefits of UTC, but never have to deal with leap seconds.<p>TAI: <a href="https:&#x2F;&#x2F;en.wikipedia.org&#x2F;wiki&#x2F;International_Atomic_Time" rel="nofollow">https:&#x2F;&#x2F;en.wikipedia.org&#x2F;wiki&#x2F;International_Atomic_Time</a>
评论 #12106677 未加载
评论 #12107282 未加载
philsnow将近 9 年前
I don&#x27;t think the article points this out, but another strong point in favor of using UTC (or anyways some timezone that (by _definition_) doesn&#x27;t have DST) is that then you won&#x27;t have discontinuities in your monitoring timeseries. It&#x27;s just lovely when you have two datapoints for &quot;cpu usage at 1:30am&quot;, similarly it&#x27;s just lovely when your alerts fire because there&#x27;s a 1h gap in your timeseries when the clocks jump forward.
评论 #12107132 未加载
billhathaway将近 9 年前
I agree with the author on having servers using UTC. The most annoying pain point for me is trying to read a log file and having to perform lots of mental arithmetic to compare it to the local time when I know the local time for an event.<p>I wrote a simple tool to translate timestamps between timezones on the fly when viewing files, although I&#x27;ve only used it personally, so I am sure there are plenty of bugs. Might be useful to someone else (or roll your own improved version).<p><a href="https:&#x2F;&#x2F;github.com&#x2F;billhathaway&#x2F;catz" rel="nofollow">https:&#x2F;&#x2F;github.com&#x2F;billhathaway&#x2F;catz</a>
评论 #12107384 未加载
CorvusCrypto将近 9 年前
Hahaha I loved this! I actually like the short style of this post. Normally I&#x27;d argue that consistency is what matters really, but I actually had not thought about daylight savings time... Short and sweet!
kimshibal将近 9 年前
My servers in SF UTC-08:00 Some guy at UTC+02:00 set his event to 2pm on 2016-07-20<p>But I need to use moment.js to display the correct time with UTC. Is there a way to handle multi timezone users without external library?
评论 #12107210 未加载
评论 #12107104 未加载
karma_vaccum123将近 9 年前
Use &quot;unixtime&quot; ints anywhere you deal with times programmatically and set the TZ to whatever you like...imho the TZ setting is for human benefit, so humans should feel free to change it.
评论 #12107036 未加载
评论 #12107130 未加载
johansch将近 9 年前
So, is it true that Google for a very long time set their servers to PDT?
评论 #12107186 未加载
评论 #12107162 未加载
simonmales将近 9 年前
My first VPS is still alive but I made the mistake of setting the timezone to that of my own.<p>Does anyone have experience with changing timezone of a server?<p>The only time I have seen time related errors when I extracting a tar file that had a future timestamp.
评论 #12106784 未加载
jaredsohn将近 9 年前
Also, if the user sets a date in the frontend, make sure it gets saved in the right timezone so that the date never changes when viewing it from a browser running in another timezone.
评论 #12107046 未加载
sdotsen将近 9 年前
My place uses GMT+4. It fvcks with us every fall.
anc84将近 9 年前
Saving you the click:<p>&gt; Setting the timezone to anything other than UTC
raldi将近 9 年前
All of the arguments in this post supporting UTC could be applied to <i>any</i> timezone without daylight saving.<p>If your company is entirely located in California or some other Pacific Time location, consider putting your servers on Arizona time. There&#x27;s no daylight saving, and for most of the year, the server time will match your wristwatch. In the winter, when California is on PST, the servers will only be off by an hour.<p>I find that much more tolerable than the hassles of UTC servers, where you can&#x27;t instantly translate between server time and wall time in your head, and server midnight rolls over in the middle of the California day, and thus datestamped logfiles don&#x27;t match up at all with your wall calendar.<p>Edit: If you&#x27;re going to downvote, please post a comment explaining why, so that readers can learn something.
评论 #12107586 未加载
评论 #12107176 未加载
评论 #12107309 未加载
评论 #12107949 未加载
评论 #12107181 未加载
bpicolo将近 9 年前
While it&#x27;s decent advice, I don&#x27;t think the reasoning here is particularly helpful.<p>&gt; DST is different in different timezones, and at some points the overlap will cause a bug when interacting with other systems<p>That&#x27;s mostly just an argument for using the same timezone in all of your systems.<p>&gt; I have (in the past), seen servers where the system timezone is set to PST, but the database is set to UTC<p>Same deal.<p>&gt; There are thousands of bugs out there that are caused by timezones<p>A google search for any other word + bug is going to give you plenty of hits too.<p>&gt; UTC assuming code interacting with non UTC assuming code can, and has caused silent data corruption<p>This is an argument for non-naive datetimes. Also is the same regardless of the two timezones involved.<p>&gt; migrating later than the start of the infrastructure can be really painful, because of your app getting coupled to the timezone it’s in.<p>That&#x27;s an argument for not changing timezones, rather than using UTC.<p>The other couple arguments are similarly moot.<p>While UTC is good, I think the key is really using consistent date handling. The most important bit is how you store them in the database, and in that regard I&#x27;m a fan of fully-non-ambiguous storage. That means either unix timestamps, or timezone-aware datetimes. Ambiguity by assuming a datetime everywhere from a data perspective is where you&#x27;ll create confusion.
评论 #12107064 未加载
评论 #12107076 未加载