Recording the time of an event is a critical function in many systems. What many developers fail to realise is that the time they're recording is ambiguous because they're not taking into account the timezone from which the time was sourced. Many applications can get away with this because their usage patterns don't expose the problems. On more significant applications it can be a real problem.
Consider daylight savings in an application that uses the current local time. When the clock moves forward there isn't a huge problem, although if you're trying to generate statistics or measure service level agreements this could be problematic. More problematic is when the clock moves backwards. You will then see the same time twice. Lacking any other information (such as ordering in text log files) the sequence of events in this time period becomes impossible to determine.
Similar problems can occur if aggregating data from multiple timezones. If you are collating, for instance, all the sales for a company with offices in multiple timezones then you must either record the timezone of the sale or normalise the times as they are aggregated. Normalisation would generally be my preference, as it makes the data simpler to work with. Recording additional timezone information runs the risk of forgetting to consider it in some calculations in additon to increasing the complexity of those calculations.
My general preference in these matters is to ensure consistency at the outset. This is most easily acheived by using UTC whenever recording a date or time value. Most platforms support this, requiring no more work than using a different method to initially retreive the date time value (assuming the system timezone is set correctly). Data from multiple sources can then be merged without having to worry about the time offset used to record it. This can be a significant advantage given the relative fluidity of daylight savings adoption and potential uncertainty as to the the timezone settings of the source systems.
Conversion from UTC to a local time is relatively straightforward and for many data items (such as logfiles) generally unnecessary. All times in this blog are expressed as UTC. This gets around any irregularities of timezones in Kentucky (where it is hosted), Western Australia (where it is authored) or viewed (which could be anywhere, but probably isn't).