When asked if they struggle with handling dates and timezones, more than 50% of developers responded "YES". My guess is that the people who said "NO" to this poll either have it figured out already, or they don't work with platforms/apps that have to cater to users across the globe.
Anyway, I wanted to create a blog post that goes into some detail on how I handle dates and timezones. I think by following these simple rules, it can be a lot less of a headache for you.
Rule #1 - STORE DATETIMES IN UTC IN YOUR DATABASE, AND BACK END CODE. It is important that there is consistency across all your date-related data. When storing dates in the database, they should always be in UTC. If you are not familiar with what UTC is, it is a primary time standard that all the major timezones are based on. The major timezones are just offsets from UTC. Furthermore, make sure the datetime is in UTC when you're handling it with your backend code.
Rule #2 - CONVERT DATETIMES TO THE USER'S LOCAL TIMEZONE USING FRONTEND CODE. Although your backend will be returning UTC times, the frontend can easily convert these to the user's local timezone. Doing this instills a separation of duties between the backend (handle in UTC) and the frontend (handle in the user's local time). Stay consistent with the format of your date times in the frontend by using a standard, such as ISO 8601. When you send requests to the backend, send the datetime in ISO 8601 format so that the backend can easily convert it to the corresponding UTC date time.
Rule #3 - USE DATETIME LIBRARIES. There exist libraries in all major web development languages/frameworks for better handling of datetimes. These make it a lot easier to do conversions, or formatting based on standards (e.g. ISO 8601). An example library to look into in JavaScript is called moment.js. An example library to look into in PHP is called Carbon.
By following these rules, you should instill an efficient PROCESS in how you handle datetimes.
Resources:
- UTC Time Standard - https://en.wikipedia.org/wiki/Coordinated_Universal_Time
- ISO 8601 Time Format Standard - https://en.wikipedia.org/wiki/ISO_8601
- Moment JS datetime library - https://momentjs.com/
- Carbon PHP datetime library - https://carbon.nesbot.com/docs/
Top comments (13)
Storing datetimes in UTC is good practice, unless you have to store future datetimes, in which case you need to save the "clock time" and the time zone, in case that time zone changes DST in the future. Kind of edge-casey but countries change their DST dates all the time, and sometimes drop in/out completely.
Asking as an Ops engineer, this sounds relevant and something to have in the "nice to know" mental-stack-but what would be an example edge-case you speak of here?
Man, I wrote some massive emails trying to work through this once upon a time, but here's a pretty simple way to think about it.
In 2005 the US moved the end of DST from the last Sunday in October to the first Sunday in November starting in 2007. So the UTC datetime for 8am November 1 in Boston in 2006 was 2006-11-01T13:00:00+00:00, but 2007-11-01T12:00:00+00:00 the following year. This is never a problem for historical dates because your TZ library knows what the UTC/DST offset was for any time zone on any date. What it does not know is what the UTC/DST offset will definitely be on future dates.
I also set all my server clocks to UTC. Especially with cloud applications, it is extremely valuable. If you happen to dual-boot Windows and Linux, Windows isn't going to like it and you have to tweak a registry setting. I have forgotten that arcane registry magic but if anyone needs it I will look it up.
Yes please :), not long ago i started dual booting and its kind of anoying having windows clock always wrong
Good rules generally, but don't forget that if you have to do time aggregation to longer time periods in your business logic, those have to be in local time. Alas, we can't keep everything on the server TZ agnostic.
I think you should have mentioned rule #0: Don't try to hack it yourself, use a library. There are far too many traps to fall into, like "in two days" is the same as "in 48 hours" but could as well be 47 or 49 hours.
And to complicate things there is also what I would call "subjective time" as I had to learn when contributing to Subsurface, a scuba diving log: Divers often do their dives at holiday destinations with time zones different from their home. They want to log things like "I did a dive at 2 p.m.". That is obviously in the time zone of the dive site. But it should still be "2 p.m." when they look at their log at home even when this is in a different time zone. This sounds like one could ignore time zones all together but unfortunately there are other relevant times that should be time zone aware like the above "let's check again for updates in two days" or when interacting with other devices like dive computers or cameras to match pictures takes to the dives in the log. In short: it's a pain!
Thanks for Recommendation, I been struggling with date and time (with timezone)
[in my Q&A site Donnekt]
I tried to make system to help me with it, But the task was tiresome!
I think using (Moment.js) will be better.
nice post! I guess I would add only one more thing is always use long format for dates
Me too :D
Use Intl.
AH! timezones are my developer nemesis 🤣 So many little, difficult-to-track-down bugs can be caused by timezones and daylight savings time... UGH!
Good points in your post :)
Don't use moment.js, it's outdated and no longer maintained. Instead, use day.js, a fast and modern alternative.