- Store dates and times in UTC for comparability, sortability, easy conversion.
- Also store IANA time zone as an attribute of the event if you need to define what tz to use for display regardless of user's current location.
In my experience the most widely recommended and used pattern is to store dates and times in Etc/UTC timezone (IANA Timezones) and to display dates and times in local time of the user viewing the information. This makes dates and times easily comparable and sortable on the server side and easily convertible to local time for display.
If your requirement is only to display local times and dates in a browser or native application based on the user's location, there is no need to store time zone for each time. Good UI tools, including browsers can convert UTC times and epoch times (which are by definition UTC) to local times.
If you have other requirements you may need to store timezone. You need to also store time zone if...for example...
You want to display an event's dates and times in local time where the event takes place, regardless of where the user viewing the information is currently located. (I believe this was your requirement.) Time zone should probably be an attribute of the event.
You ever need to produce output in a user's or event's local time from your servers. Examples: pdf's, e-mail content, paper that is produced on schedule and not directly in response to a user's request. In this case time zone could be a user preference, or an event attribute.
If you are going to store timezone you should generally use IANA time zones such as Etc/UTC and America/Los_Angeles. They are the most widely supported by development tools, time libraries etc. They are convertible to windows time zones (see this question)
Not Enough Details? - Why are offsets different from time zones?
Storing a UTC Offset such as -08:00 is not the same as storing a time zone. A UTC offset is valid to store, retrieve and display a specific time such as 2017-09-09T12:00:00-08:00. It allows you to display that local time at any time in the future and to convert it to UTC.
Depending on the tools you use, storing an offset may not meet your requirements. For example:
- The offset alone does not tell you what time zone the event is in.
- If you need to record or schedule another event on a different date at the same location, you can't just assume the offset from the last event is re-usable.
- The offset -08:00 can be America/Los_Angeles or America/Anchorage or America/Tijuana, for example. Mexico and the USA start DST on different dates since 2007. So you need a time zone to know what offset to use on a new date.
- You can't figure out an event's time zone reliably from the UTC offset of the user's browser or local OS.
- Even if you get user's timezone from one of the browsers that supports it or from their local OS, is that user on a beach in Mexico while planning an event in Los Angeles?
- So when you record an event, how do you know which offset to use?
- Will you ever need to present time zone to users? Will you say: "Come to our big bot battle in San Diego or watch it live on botwars.net at 8pm UTC -07:00!"
Your requirements may dictate that you have more need to know the time zone of an event than the offset of any times associated with the event. This allows you far more flexibility in what you can do later. You can always recreate offsets from a time zone using a good time library. You cannot always reliably infer timezone from an offset.
Should you implement all of this yourself? No. There are plenty of good tools to help. Be sure you read the limitations of database time types and other tools before you use them. There have been a surprising number of problems with language and dbms support for time, and fortunately quite a few time/date libraries that pick up the slack.