Datetime values should always be stored in UTC. Makes sense, but what about the datetimes embedded by a camera in a JPEG file? Ideally, these would be stored in a timezone-aware format, but sadly Canon cameras do not do this. No matter, because the JPEG EXIF format can't store timezone information anyway!
Until now I have always tried to keep my camera set to "local" time, whatever that might mean. I usually remember to change it when going on holiday, but I often forget to change it during the switch from GMT to BST. This matches the behaviour of most phones, which will automatically adjust their date and time settings (and hence phone-camera image timestamps) when you move to another timezone. (The exception is if you have a GPS-enabled cameraphone with geotagging enabled, in which case the GPSTimeStamp tag will always be stored in UTC).
Unfortunately, I'm now more and more convinced that changing time manually is the wrong thing to do. It's far too easy to forget whether you have made the adjustment, and thence risk making an extra unneccessary adjustment later further down the workflow pipeline. I'm very fortunate in living in a timezone which is identical to UTC for most of the year, so it's an easy decision for me to make: I will now always keep my camera clock and EXIF timestamps set to UTC.
This doesn't compensate for the lack of knowledge of timezone, so I now have to think of a way to accurately record this too. It also doesn't account for the now-infuriating behaviour of my phone, which I can't set to anything other than local "network" time. Fortunately, my network has foreseen this problem and set its roaming rates so high that I never use my phone when abroad and thus will presumably not encounter this problem too often.
Update 2011-04-09: Forget all that. I'm still confused, but now leaning towards keeping the camera set to naïve local time, and recording the timezone separately.