Hm, no offence, but what's the use of this plugin if it doesn't take care of DST automatically? If you have to remember the date to turn it on and off and have to access the plugin manager and install/uninstall the plugin on that date, what would be the benefit? You could just as well go to Coppermine's config and change the time offset there.
To turn this into a really usefull plugin you would have to add a table (a simplified version of
http://www.timeanddate.com/time/dst2010.html ff.) where all the dates are being kept on which the DST will be turned on/off for the next few years. Remember that this differs from country to country, so you'll have to provide a plugin config option to specify the country the user is in. We wouldn't want to run a query against that table though each time the script is being accessed, so we'd have to apply some caching mechanism. The best way to deal with this would be storing the next date when the time needs to be re-adjusted within an additional config field (something like
plugin_dst_date) and only trigger the repopulation of that field once with a separate function that only get's executed once per DST change.
The plugin itself would then be triggered by something that happens each day (the
page_start action is fine), but it would have to check if we're currently in the DST period for the country initially specified and if yes add another hour to the time offset as you currently do.
Bottom line: I would find this helpfull if it could work automatically and would like to see this implemented in a future version of Coppermine inside the core. If you agree I can come up with a draft how I would accomplish what I suggested above.
Cheers
Joachim