I reiterate that if you store localtimes, you are probably storing headaches for the future, if your stuff ever needs to go anywhere near an international terminal.

If you absolutely have to store localtimes, remember that their meaning will change whenever your servers are relocated to another zone (India?), or whenever your server/web/mainframe/user environments are tweaked by a kindly ol sysadmin.

I'm not sure if the nightmare you mention is a) because your currently stored data is in localtime (sic), or b) because you think it is hard to convert that to UTC? In any case, you don't have to change the entire world - just the corner you are responsbile for :)

Systems I work on currently have trading and operations users in 8 timezones at about 70 financial institutions. The timing of market pricing is a critical question, often asked - usually in the context of 'How old is that price' and 'When did you take that price' - especially where the same instrument trades on multiple exchanges and they are looking at comparative time-series data. There is a minor gotcha when comparing a trading day across multiple timezones - but we track effective_date distinctly from price timestamp.

In all cases, they expect the answer in their local timezone - storing it in UTC makes it a cinch to keep it all clear for users in AEST, EST, BST, CEST/CET, HKT, SGT, PHP, ETC.

As well as web-based presentation, we use the UTC timestamps for Excel and PDF extracts, and system data / XML extracts. The extracts are used on a variety of UNIX and mainframe OSs - in all cases, the standard TZ libraries make it easy for users and developers to know precisely what the timestamp means to them, and to present it in any timezone they choose.

Interestingly, one site submits its US data from a US mainframe, using EST and EDT timestamps - what a PITA to get this data synchronised with everyone else in the world... reminds me of that old favourite financial system design pattern: 'Currency? what currency? we only ever transact in Dollars!'

So, by all means store localtimes, but only do it consciously, after having properly considered the potential issues.