When dealing with most point-in-time values (created at, updated at, expires at, scheduled for, etc), it's not necessary to store the time zone of the user.
The idea is to realize that the time zone is just a presentation/communication detail of an absolute concept: instant in time. Although, time zones are a very important thing to consider, neither the application nor the user actually care about time zone all that much.
- The server. Needs an absolute way to store and compare instants-in-time reliably.
- The user. Needs to see instants-in-time, always presented in his/her time zone.
- The back-end only deals with datetimes in a single time zone: GMT.
- The front-end only deals with datetimes in a single time zone: Local time (user)
This keeps both the server and front end simple, as they only ever have to deal with one time zone. And it puts the time-zone code in one place: the controller layer.
- The browser makes request to the server (includes tz-offset cookie automatically). Any datetime in the request is sent in the end-user's timezone (the one from the cookie), but the time zone is not included in the datetime (it's already on the cookie).
- The server uses the time zone offset from the cookie to transform any datetimes found in the request to GMT.
- From that point on, it's GMT all the way to the DB.
- When the server obtains data from the database, any datetimes retrieved are in GMT.
- As the server prepares the HTTP response, it uses the tz-offset value from the cookie to transform the datetimes in the response to the correct time zone for the user.
- Set all servers (OS, Database, Web Server, etc) to GMT
- In the database, store every datetime representing a point-in-time in GMT.
- Write all your backend code assuming GMT.
- Include end-user's tz-offset on all requests.
- Don't burden the browser with time zone calculations. Once it reaches the browser, all times should be in the user's time zone already.
- Recognize date/times that are not absolute instants-in-time and treat them different (office hours, broadcast times, etc). For these, you will need to keep track of the time zones in the database and your backend code will have to deal them explicitly.