Local Time is not for the Server, Use UTC

Local Time is not for the Server, Use UTC

When developing a website, knowing about the important parts of server-client communication is very important. Like many non-professional programmers, I learned my way around by trial and error while using Stack Overflow whenever I had a question. It’s commonly agreed that this is the best way to learn programming, even though we do it naturally. Most don’t purchase a book to learn programming. But although this natural technique is great for learning front-end and back-end development quickly, you can end up missing out on the standard practices that take lots of experience to learn. One of those fundamentals – your server-side should always use the UTC zone.

Recently I saw a post on an online programming forum that was attempting to store the programmer’s local time zone on the server side, rather than the client side. When the client uploaded something, say a calendar event, the date would be sent as a local time to the server. Since this person found that the Date elements were automatically converting to UTC on the server side, they tried to falsify the local time as UTC so that it would display the way they wanted for server outputs. But once they tried to send it back to the client, the client interpreted the UTC and converted it to an incorrectly offset time. It’s hard to blame this person when there is not much real documentation online about handling time, but there’s a simple way to do it the right way and save the hassle.

Since we are talking mainly about web development, I will be using JavaScript’s Date functions to demonstrate. It should be similar in other languages too. When I talk about converting, I will also reference Unix time, which is an integer counting the milliseconds from Jan 1, 1970, rather than a human-readable string. Both are equally functional when using the Date object, but UTC is much easier to read for output. Anyways, here’s how it should work: The client side is exclusively responsible for the display of dates and times to the user in the local time. Networking logic received or transmitted the sby erver should be handled in UTC. I’ll give one example for the case of a plane arrival website for employees. The employee’s client should always receive that time in UTC (or Unix time), turn it into a Date object, and then use .toLocaleString() to display it. If the employee had to confirm when a plane arrived, they would input a local time, turn it into a Date object, and then use it.UTC() (or .valueOf() for Unix) to create a string to be sent to the server. This way, the server is always operating under UTC. Technically, you could send local time ISO strings to the server and convert them, but this way you can store UTC times immediately. Your databases all use the same time zone.

If you plan on handling times manually rather than using the Date object, which isn’t recommended, using local time becomes even more of an issue. Because many locations have Daylight Saving Time, where the time skips or omits an hour at points during the year, there is a lot of extra logic required. All of this logic would eventually lead you to the conclusion that a continuous time zone, like UTC, would be the best route to go. The reason that UTC is the best choice is because it has the best native support in many languages. For example, using an EST time zone (without switching to EDT) won’t have Date support for anything besides display purposes. Some languages may have the functionality to allow you to run your server under your local time zone, but it’s probably best just to unify with a one-time zone for project scalability. Professionals expect UTC to be the time zone and it may become a hindrance if all data is handled under an unusual time zone. And other languages may require a custom Date functionality just for it to be compatible with your existing databases.

So, in summary, use UTC on your server First, you don’t have to employ techniques to work around your programming language’s native functionality. Second, it makes your databases easier to read and compare. And finally, although there are many other positives, it is a standard continuous time zone used by most professional programmers. I wish that more programming documentation online mentioned this because it seems to be commonly left out. Now you know the reason behind why this certain time zone is used and how it can help you stay organized. Always use UTC on the server side.

United Hacks HackathonHack United Social Media • Written By Josh Rodgers.