[sicxu]

I would not go with the approach of storing timezone and formatted date/time in two seperate char columns. You need to really seperate date/time information into two parts, the absolute time and it's presentation. Usually, you only store the absolute time in database and control timezone at session/user level. You always apply timezone when you present date/time information and always convert date/time to absolute time when you store it.

[benmmurphy]

+1. i think the only time you need to store timezones is when you don't have an absolute point in time. say you are storing a time without a date. ie: 5:00pm. you need a timezone associated with that time somehow.

[sicxu]

Yes. When you schedule a recurring event, such as daily reminder, you will have to store timezone. In that case, you are storing a scheduling specification, not a real date/time. You don't have the complete information, such as year/month, etc.

[obtu]

You missed one of his requirements, which is he wants be able to compute "three months after" on the dates he stores, which is a timezone-sensitive calculation. This sort of requirement is commonly found in calendaring. That means he does need to store symbolic information for each date or datetime stored.

[sicxu]

You need timezone for sure. You just don't have to store it along with every date/time value. You can store it as user preference for example. What if you are scheduling a meeting between a U.S developer and an India developer?

[obtu]

The date of the meeting mustn't depend on the display preferences of one of the participants. The meeting itself has to be anchored to a time zone.