I feel like nobody has given a very clear answer, here. For future events, a UTC timestamp is insufficient because it doesn't take into account timezone-db changes (like the US now going to permanent DST). And you can't fix it after the fact, because even if you stored the offset, that's not sufficient to know whether someone is in the US (which is changing) or just somewhere sharing that offset on that date.
If I already have something scheduled for 9am in the US on some day in December, on systems like yours, where you're assuming UTC is fine and complete, it's now going to be an hour off. It's not even the first time the US has been affected - there were lots of issues with alarm clocks going off early/late and similar after they changed the dates of DST.
The ideal way is to store a timezone (like "America/New_York") for the event and the time in local time. If you have efficiency concerns, you can also store a redundant UTC copy but you'll need to remember to keep updating it. Also, you may need to store the user/entity for the event, so you can handle the user themselves changing their location (if you're running an internet alarm clock system).
Be warned, btw, that "GMT" is now ambiguous; Windows 95 called "BST" (British Summer Time) "GMT Summer Time" and it seems to have stuck and so "GMT" means current UK time for many. (Language evolves, even when technical users don't want it to.)
If I already have something scheduled for 9am in the US on some day in December, on systems like yours, where you're assuming UTC is fine and complete, it's now going to be an hour off. It's not even the first time the US has been affected - there were lots of issues with alarm clocks going off early/late and similar after they changed the dates of DST.
The ideal way is to store a timezone (like "America/New_York") for the event and the time in local time. If you have efficiency concerns, you can also store a redundant UTC copy but you'll need to remember to keep updating it. Also, you may need to store the user/entity for the event, so you can handle the user themselves changing their location (if you're running an internet alarm clock system).
Be warned, btw, that "GMT" is now ambiguous; Windows 95 called "BST" (British Summer Time) "GMT Summer Time" and it seems to have stuck and so "GMT" means current UK time for many. (Language evolves, even when technical users don't want it to.)