I think a lot of the earlier comments have been oversimplistic - it's not just a matter of saying "UTC is best, stick time localisation in the presentation or application layer" and assuming that will always give you the best solution. What time zone is best to use in the database will depend on your system and on the circumstances in which you are building it.
If your system is inherently local (for example an in-room entertainment system designed to support a single hotel) then local time is going to be best. You may need a table showing when "summer time" started and ended in various years if you have to export MIS data to an HQ in a different zone but usually I would consider any such need to be a consequence of really stupid design of the MIS system (in the example suggested above I won't want to know what the hotel's customers were billed for access to VoD, MoD, Office Apps, Pay TV, Internet etcetera in a specific 24 hour period defined by my headquarters clock, be that UTC or not, what I need to know is what they were charged in a period for which I will bill the hotel which is of course defined by the local clock at the hotel).
If your system is inherently global, and not inherently calendar-day oriented, then time should be stored in UTC and the data layer should not provide any zone conversion - the application layer can do that. Probably an inherently global system should adopt that approach even if it is calendar day oriented, but I think there may be exceptions - it needs to be looked at for each particular case.
If your system is initially local but may grow to spread across time zones, you have a trade-off between a delay in deployment (and extra start-up costs) to do it with UTC and zone conversion above the data layer, and doing it with local time but planning to change over in future before (not when) you need to go global (which is likely to be more expensive in the long run, but that won't matter if doing it is the only way you will see the long run because the extra initial costs and deployment delay of doing it right first time would put you out of business - this really is a case when doing it wrong first may be better, and it has to be looked at very carefully).
So don't let assumptions about what is "obviously" best make you fail to do a proper analysis of what is best for the system you are building in the circumstances in which you are building it.