Using Moment Timezone for Future Events, What should I save?

I have done a fair amount of research, and new to the idea of programming with time.

I have an application where you must be able to schedule a meeting in local time. So you might say "23rd December 2017 at 9am in San Francisco". The Event Location is the perspective of time. It may also recur which is a different issue but related.

When I am creating an event, I know that I should not store future events in UTC. I believe I need:

The Local Date Time
The UTC Offset
The Olson Database ID Europe/London perhaps

However, I plan to use Moment Timezone both locally and on the server portion.

By using this library. How does that change my outlook? Does it mean I no longer have to be concerned about Daylight Saving Time? That if you tell me "2017/12/12 09:00", I could turn that into local time accurately for any timezone in the world?

So all I really need is:

The Local Time and Date (As an ISOString?)
The Olson TimeZone ID.

Later on the server, when I want to send out a Push Notification 1 hour before the Event. These 2 properties (and Moment Timezone) should have me covered?

Solution

You can convert local times reliably with moment-timezone very easily:

var original = moment.tz('2017-12-23T09:00:00', 'America/Los_Angeles');

var easternUS = original.clone().tz('America/New_York');
var centralEU = original.clone().tz('Europe/Berlin');
var westAUS = original.clone().tz('Australia/Perth');
var japan = original.clone().tz('Asia/Tokyo');
// etc.

(Use .format(...) to produce a string with the desired output.)

You can also easily calculate the time one hour earlier with any normal Moment functions.

var earlierUTC = original.clone().utc().subtract(1, 'hour');
var earlierEastern = easternUS.clone().subtract(1, 'hour');

Yes, as you can see, all you need to store is 2017-12-23T09:00:00 and America/Los_Angeles.

One might consider storing the event time with an offset, such as 2017-12-23T09:00:00-08:00, but you run into a few problems there:

What if the event reoccurs monthly? When DST starts in March, you'd have to decide whether to keep the local time at 9am and change the offset to -7, or whether the original intent was the equivalent UTC time (17:00Z), which would move the local time to 10am.
What if the politicians change the time zone or DST rules before the event takes place? This is unlikely in California this year, but it does happen under short notice with some regularity on a global scale. See my blog post On the Timing of Time Zone Changes. Even in California - say it was an annual event that took place in the summer, but then say a bill like this one was passed into law - your offsets would be wrong.

There is one point you should think about. What do you do if an event local time is invalid or ambiguous?

Invalid times happen on spring-forward transitions. For example, the clock moves from 1:59 to 3:00 but you have a 2:30 event time. This is unlikely for a single event, but could easily happen with a recurring one. You'll have to decide how you want to handle this, but if you're not sure then I suggest advancing the local time by the amount of the gap. So the event would be at 3:30 that day, then go back to 2:30 on the next occurrence.
Ambiguous times happen on the fall-back transitions. For example, the clock moves from 1:59 back to 1:00. If your event runs at 1:30, you'll have to decide whether to run on the first instance, the second instance, or both. In most cases, I suggest running on the first instance (which happens to be the daylight time, not the standard time).

If the event really only ever runs one time, and it could be during a fall-back transition, then it would be ok to disambiguate by recording the event time in UTC or in local time with an offset. Just watch out for changes in the time zone rules as I mentioned earlier.

Moment-timezone automatically applies the above suggestions during its conversions, so unless you have a reason to deviate - you don't have to worry about it.