It's cases like this that show that you should use a proper timezone library in your code. Too often I see websites where the timezone field is given as "+/- X from GMT". Just store everything in UTC, and use tzdata fields (e.g. "Europe/London") to convert to something nice to show the user, and People Cleverer Than You™ will make sure everything works.
While it's better than nothing, doesn't solve the problem of the future legislation. Real example from the corporate life (specific software in this case was Exchange/Outlook): meeting is scheduled between Seattle and Beijing locations, US changes start date of the date-light savings time. One of the meeting times needs to be updated, so people would still meet at the same time, but whatever time you update you move meeting by one hour at this location, creating conflicts and upsetting users.
Even simpler problem is not so easy to handle in software: if you save dates in UTC, once DST start date changes, all your meetings move one hour, but most meetings are scheduled in "local" time, i.e. dentist still expectes to see you at 10am.