[rmc]

Yes, you're right. In cases like that you should store future events as local time, and wait until a resonable time before the event (e.g. a week) to convert from local to UTC. Then you will have (hopefully) an updated tzdata file.

[notatoad]

what? no, that is a horribly convoluted solution to account for a rare edge case. store UTC and an olson string, and if people live in an area where the dates change, it is their responsibility to move their appointments. if you want to be really nice, you could run a batch job to switch all effected events a day forward.

[andrewaylett]

I disagree -- in this case, you should consider storing local time and the Olson tz it's due to be in. Microsoft make the mistake of doing it your way in Outlook, meaning that everyone had to update their calendars when the US changed their DST rules.

Events in the future are commonly scheduled relative to what the time is going to be in a specific place, regardless of how the tz rules change in the meantime. Automated actions in the future, however, may well need to be fixed to a UTC time. In short: you need to think about how your system will actually be used, and possibly store values differently depending on how they will be used.

On no account ever use a raw UTC+n offset.