8 ms·
Set server timezones to UTC
- anc84 10y agoSaving you the click: > Setting the timezone to anything other than UTC
- bpicolo 10y agoWhile it's decent advice, I don't think the reasoning here is particularly helpful. > DST is different in different timezones, and at some points the overlap will cause a bug when interacting with other systems That's mostly just an argument for using the same timezone in all of your systems. > I have (in the past), seen servers where the system timezone is set to PST, but the database is set to UTC Same deal. > There are thousands of bugs out there that are caused by timezones A google search for any other word + bug is going to give you plenty of hits too. > UTC assuming code interacting with non UTC assuming code can, and has caused silent data corruption This is an argument for non-naive datetimes. Also is the same regardless of the two timezones involved. > migrating later than the start of the infrastructure can be really painful, because of your app getting coupled to the timezone it’s in. That's an argument for not changing timezones, rather than using UTC. The other couple arguments are similarly moot. 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'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'll create confusion.
- philsnow 10y ago> > DST is different in different timezones, and at some points the overlap will cause a bug when interacting with other systems > That's mostly just an argument for using the same timezone in all of your systems. The TZ database is not static. Governments have a habit of monkeying with DST definitions to suit their whims. Several of your systems may have TZ updates come out at different times. Debian/java/erlang/windows have different rollouts for the TZ database that you have to coordinate somehow if you want all your systems to agree on the time/date. Just use UTC.
- bpicolo 10y agoI do think you should use UTC everywhere. I just don't think the article makes the best argument for it.
- y4mi 10y agoisn't utc the default timezone everywhere? you're often asked on the setup script, but it mostly defaults to utc if you do an automatic installation and don't specify the timezone.
- azdle 10y agoWhy not use TAI? You get all the same benefits of UTC, but never have to deal with leap seconds. TAI: https://en.wikipedia.org/wiki/International_Atomic_Time https://en.wikipedia.org/wiki/International_Atomic_Time
- lttlrck 10y agoThe second offset may be awkward when comparing logs, network traces etc across systems that you may not control.
- dietrichepp 10y agoConverting between TAI and UTC requires tables that must be periodically updated and distributed to any system that converts between the two. Smooth UTC is a good alternative for most computing applications.
- baq 10y agoI always assumed you need such a table anyway to know when leap seconds happen...
- dietrichepp 10y agoYes, but if the machine clock is synchronized to UTC the machine itself doesn't need the table, and you only have to distribute the table to a small number of NTP servers.
- CorvusCrypto 10y agoHahaha I loved this! I actually like the short style of this post. Normally I'd argue that consistency is what matters really, but I actually had not thought about daylight savings time... Short and sweet!
- simonmales 10y agoMy first VPS is still alive but I made the mistake of setting the timezone to that of my own. Does anyone have experience with changing timezone of a server? The only time I have seen time related errors when I extracting a tar file that had a future timestamp.
- dozzie 10y agoYou need to put appropriate (binary) file to /etc/timezone, or historically, a symlink to a file under /usr/share/zoneinfo/.
- drdaeman 10y ago"Historically"? You mean symlinks are discouraged/deprecated nowadays? I only heard about the early-boot issue wish separate /usr partition. Is there anything else? As for early-boot issue - I'd say it's uncommon to have /usr on separate partition from / nowadays, and those who do this must know what they're doing. Less likely to happen than ad-hoc manual (non-packaged) tzdata update not catching up.
- dozzie 10y ago> "Historically"? You mean symlinks are discouraged/deprecated nowadays? I saw somewhere a comment from a distribution (it was Red Hat, I believe) saying that some programs could have trouble with a symlink. I've never encountered such a program and I could easily live with a symlink, but Debian (my current main distro) went with a file copy, so I didn't bother.
- johansch 10y agoSo, is it true that Google for a very long time set their servers to PDT?
- Symbiote 10y agoDon't they still? I see headers like this in GMail: Received: … Sat, 16 Jul 2016 10:35:05 -0700 (PDT) which gives me two calculations to get to my own timezone, rather than just one. The same offset is in headers from Facebook and Microsoft, though Oracle have UTC.
- mwfj 10y agoThat doesn't say anything about the servers timezones. SMTP is a service on top of those.
- deleted 10y ago[deleted]
- sdotsen 10y agoMy place uses GMT+4. It fvcks with us every fall.
- jaredsohn 10y agoAlso, 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.
- jjnoakes 10y agoOr, just translate the date from the user's local time to UTC as it is entered and stored, and display it in the local time of whoever is looking at it (or use UTC if the user wants to see it in UTC), so you don't have any confusion.
- jaredsohn 10y agoSorry, I should have been more specific. I meant to say that if a date is associated with some location (such as on a travel site) then you need to make sure that that the date gets stored for the timezone of that location and that you keep track of what the timezone should be so you can use it when displaying it again. For example, if you have a flight leaving SFO at July 16, 2016 4:00 PM PDT, you don't want to show it as July 16, 2016 1:00 PM if viewing it from New York.
- jjnoakes 10y agoThis thread was about changing time zones though. If you have a local time and you don't need to change time zones, then of course it is fine to store it as local time.
- x1798DE 10y agoFor events in the future, the mapping between local wall time and UTC is not fixed (consider that Egypt recently cancelled DST on three days' notice), so if the time that matters is local wall time, you should not store your days as a UTC time stamp, you should store it as the local wall time with a zone or location identifier (generally use an Olson TZ if possible). If you're storing time stamps (i.e. you care about how many seconds have elapsed / will elapse since / until the event), your strategy is the right way to go.
- kimshibal 10y agoMy servers in SF UTC-08:00 Some guy at UTC+02:00 set his event to 2pm on 2016-07-20 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?
- pinum 10y agoI'd personally just keep using Moment. The pain of working with JS Date objects isn't worth saving a few tens of KiB/a few ms of parsing time.
- jaredsohn 10y agoMy understanding is that Javascript Date objects only let you display dates in either the browser timezone or in UTC. If you want to display dates in another timezone you need to use a library that does that for you or write a function that adds/subtracts hours/minutes based on the offset. I'd recommend using a library.
- karma_vaccum123 10y agoUse "unixtime" 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.
- jjnoakes 10y agoThis is of course the right solution in theory, but in practice, tools you don't have much control over use local time, not UTC, when interacting with the user. Cron is one example. It isn't trivial or intuitive to set up your crontabs in UTC; it should be, because that makes the most sense on a server (especially during DST transitions), but since it isn't, you either have to set your system time to UTC (as the article suggests), hack around it (changing the cron program on all machines you care about), or be aware of the pitfalls (like DST transitions).
- thwarted 10y agoFrom the ISC crontab(5) man page: The CRON_TZ specifies the time zone specific for the cron table. User type into the chosen table times in the time of the specified time zone. The time into log is taken from local time zone, where is the daemon running. I use this all the time to set job times relative to a specific timezone while the server time is in UTC. It is trivial and makes setting the times largely intuitive.
- Symbiote 10y agoI tried this for a while, but it was more confusing. Logfiles would be written with UTC times, but the time showing on my terminal prompt, or if I ran `date`, was in my local time. (Possibly more confusing to me, as I live in Western and Northern Europe, with +0000, +0100 and +0200, so it's easy not to notice the time is offset from UTC in a logfile.)
- philsnow 10y agoI don't think the article points this out, but another strong point in favor of using UTC (or anyways some timezone that (by _definition_) doesn't have DST) is that then you won't have discontinuities in your monitoring timeseries. It's just lovely when you have two datapoints for "cpu usage at 1:30am", similarly it's just lovely when your alerts fire because there's a 1h gap in your timeseries when the clocks jump forward.
- markbnj 10y agoThe OP sort of touched on this with the point about "some jobs going missing" at the transition points. It's roughly the same issue I guess. Anyway will certainly join in the chant of UTC, UTC, UTC. Not long ago I had to manage some boxes at different colo datacenters where I had some on pacific time, some on central. It's a huge pain figuring out when things actually happened.
- raldi 10y agoAll of the arguments in this post supporting UTC could be applied to any timezone without daylight saving. If your company is entirely located in California or some other Pacific Time location, consider putting your servers on Arizona time. There'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. I find that much more tolerable than the hassles of UTC servers, where you can'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't match up at all with your wall calendar. Edit: If you're going to downvote, please post a comment explaining why, so that readers can learn something.
- karma_vaccum123 10y agoUgh, daylight savings time and "imperial" measurements are two things I would just order away if I could be granted dictatorial powers for one day.
- deleted 10y ago[deleted]
- tbarbugli 10y agoWhat if Arizona decides to adopt DST?
- waterphone 10y agoIt's unlikely to. Residents of a state where summer temperatures get well over 100° regularly don't want summer days to be even longer. The few attempts to do so (for no good reason) have always failed spectacularly, and most Arizona residents are very pleased with it the way it is.
- dragonwriter 10y agoDST had no effect on day length. It has an effect on which actual hours of the day are outside of conventional working hours.
- billhathaway 10y agoI 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. I wrote a simple tool to translate timestamps between timezones on the fly when viewing files, although I'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). https://github.com/billhathaway/catz https://github.com/billhathaway/catz
- deleted 10y ago[deleted]