What about: * ID: auto-incremented integer * Name: string * StartTime: date/time in UTC * Address: string * TimeZoneId: Europe/Amsterdam * RuleEffectiveTi

What about: * ID: auto-incremented integer * Name: string * StartTime: date/time in UTC * Address: string * TimeZoneId: Europe/Amsterdam * RuleEffectiveTime: date/time in UTC The rule effective time represents when the start time was last changed, converted to UTC. Next, create a time engine that can convert between events (time + location). The engine can convert events to different time zones in different epochs, to UTC, or the other way around, because it knows all the rules, and when the rules changed throughout history. A simple API will handle things: time time_engine.parse_time(rule_effective_time_event, string_representation) String time_engine.to_presentation_string(rule_effective_time_event, time_value_utc) Where time_event is a tuple consisting of the rule effective time, and the timezone whose rules to apply. When the venue changes, you update TimeZoneId. When the start time changes, you change StartTime and RuleEffectiveTime. The time engine would only be invoked to present the start time in current time + zone format for the user to modify in their own temporal space, then to parse the changed time back to UTC using the user location + new RuleEffectiveTime (which is now). Timezone rules are fixed as events in time and space, so every rule effective time + time zone + utc_time will uniquely point to a specific time zone rule, which means that the rule itself doesn't need to be stored in the database. Timestamps are also fixed, and should never change (unless the user changes the time for the meeting, of course). You could build the time engine to preserve absolute time (14:00 becomes 15:00 after the rule change), or to preserve local time (14:00 remains 14:00 after the rule change, even though it's technically a different time). You could even change how the engine behaves after data has been created, since it's only affecting how things are interpreted locally to the user. The data remains the same no matter what. The database's role is to store data, not to decide rules. Store the data, not the rules.