Bachelor's and Master's in CS from MIT. Previously, worked @ Microsoft & Zynga. Currently Co-Founder of Moesif (moesif.com), the most advanced API analytics platform.
Agreed. At database level (or even backend, e.g. your restful API) do everything in UTC or epoch time (which is just an integer in milliseconds since Epoch time (00:00:00 Coordinated Universal Time (UTC), Thursday, 1 January 1970.)). Either epoch time or UTC time is fine.
At UI level (i.e. clientside), where you have the timezone of the user (which you can get from the system, either inside browser or mobile app), convert to to localTime before you display it.
Because of that, in most cases, you don't really needs to store the timezone of the user. Unless you plan to send email or something from backend that you want to show the time based on the localTime of the user. Then you may want to store the timezone of the user in his user profile. And only need convert to the user's localTime right before you sent out the email.
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
Agreed. At database level (or even backend, e.g. your restful API) do everything in UTC or epoch time (which is just an integer in milliseconds since Epoch time (00:00:00 Coordinated Universal Time (UTC), Thursday, 1 January 1970.)). Either epoch time or UTC time is fine.
At UI level (i.e. clientside), where you have the timezone of the user (which you can get from the system, either inside browser or mobile app), convert to to localTime before you display it.
Because of that, in most cases, you don't really needs to store the timezone of the user. Unless you plan to send email or something from backend that you want to show the time based on the localTime of the user. Then you may want to store the timezone of the user in his user profile. And only need convert to the user's localTime right before you sent out the email.