Standard PSA: Do note that storing future times only in UTC can lose important information for almost everybody at some point. When a country changes its daylight savings time dates (as happens regularly and has happened before for the US) or decides to stay in daylight savings forever (as the EU and US are both proposing), any future events stored as UTC may then be at an incorrect local time.
The safest format for a stored future timestamp is a local time, an IANA timezone name, and, if you need it for efficiency, a derived UTC time. But you need to rederive the UTC time whenever the timezone database changes (or whenever the related entity/user changes their timezone), or it may become incorrect, as above.
If you're worried about the future timestamp being at a specific local time (say 10 AM on a future date), it's actually better to store a naive time and a location than the IANA timezone name.
Then, if a state decides to stop doing DST, or any other funkiness like that, you can still get the time right.
What if my country splits itself in two, and the location “Oslo/Norway” that used to describe my time zone no longer describes the place I live. And they change the time zone offset to be one hour off from what it used to be for Oslo/Norway but in the place I live the time zone offset remains as it was before the split?
Don't use Oslo/Norway if you're in e.g. Trondheim; store Trondheim/Norway.
I should note that it is not possible to make a database of geolocation->UTC offset that is legal in all countries, since there are countries with disputed borders, some of which care very much that no software imply the "wrong" border.
> If you're worried about the future timestamp being at a specific local time (say 10 AM on a future date), it's actually better to store a naive time and a location than the IANA timezone name.
Europe/Oslo would be the IANA name for mainland Norway (Svalbard and Jan Mayen are in different IANA regions).
If you're meeting somewhere at a specific time, you might as well specify that place really precisely (Maybe: Nidaros Cathedral, Trondheim, Norway) and then use that place to infer the proper UTC offset when the date approaches.
There's no perfect solution as landmarks, names, &c. can all change.
The safest format for a stored future timestamp is a local time, an IANA timezone name, and, if you need it for efficiency, a derived UTC time. But you need to rederive the UTC time whenever the timezone database changes (or whenever the related entity/user changes their timezone), or it may become incorrect, as above.