This is the right solution. You don't check for any changes every single time you read out a timestamp - that's just unnecessary overhead and removes the abilit

This is the right solution. You don't check for any changes every single time you read out a timestamp - that's just unnecessary overhead and removes the ability to write simple queries to search for timestamps within a certain range. You store the timestamp, and a foreign key to the timezone as it was defined at the time the timestamp was inserted (orginal revision). You then schedule a sweep (every day, say) that simple detects which timezones have received an actual update, then select/update any rows which were created with the previous timezone entry. Not very difficult to implement, and generates the minimal amount of overhead possible. The only exception is the one raised by laut regarding an event scheduled for say 02:30, and where 02:30 simply does not exist after a rules update. The sweep can detect these and in theory should alert the user to the inconsistency. An annoying edge case to be sure. :/