Storing epochs for future times that are specified in local time usually isn't enough considering that local time zones change. If you only deal in times and ti

Storing epochs for future times that are specified in local time usually isn't enough considering that local time zones change. If you only deal in times and time zones where time zone changes are announced far enough in advance that zone changes can be processed before any events they effect are in the system, it doesn't matter. But if people schedule things years out in countries with reasonable notice, or weeks out in countries where there's a lack of notice, there's a good chance of doing things wrong. To accomidate these future dates, you should store the localtime and you should also store the offset and/or an epoch determined at time of storage. When rules change, you should evaluate future events and for events where the calculated epoch changes, storing and using the new epoch is a sensible default --- you should ideally show the user a summary of changes, so they can adjust if they have things that were entered in local time for convenience but are actually scheduled in a different zone.