timezone issues

Summary of answers and other data: (please add yours)

Do:

• Whenever you are referring to a particular moment in time, persist the time according to a unified standard that is not affected by daylight savings. GMT and UTC have been mentioned by different people, though UTC seems to be mentioned most often.
• ?? Include the local time offset as is (including DST offset) when storing timestamps. ?? Store timestamps as UTC or epochs(number of seconds since 1970) without time zone or offset.
• Include the original time zone name, so you can reconstruct the original time at a later point and display correct offsets if needed.
• Remember that DST offsets are not always an integer number of hours (for example, Indian Standard Time is UTC+05:30).
• If using Java, use Joda Time.
• If using .NET, consider using Noda Time.
• If using Perl, use DateTime.
• If using Python, use pytz
• If using PHP > 5.2, use the native time zones conversions provided by DateTime, and DateTimeZone classes. To keep PHP with up to date Olson data install periodically this PECL package. See answer
• Create a table TZOffsets with three columns: RegionClassId, StartDateTime, and OffsetMinutes (int, in minutes). See answer
• Business rules should always work on civil time (UTC/GMT).
• Internally, keep timestamps in something like civil-time-seconds-from-epoch. See answer.
• Only convert to local times at the last possible moment.
• Remember that time zones and offsets are not fixed and may change. For instance, historically US and UK used the same dates to 'spring forward' and 'fall back'. However, in the mid 2000s the US changed the dates that the clocks get changed on. This now means that for 48 weeks of the year the difference between London time and New York time is 5 hours and for 4 weeks (3 in the spring, 1 in the autumn) it is 4 hours. Be aware of items like this in any calculations that involve multiple zones.
• Consider the type of time (actual event time, broadcast time, relative time, historical time, recurring time) what elements (timestamp, time zone offset and time zone name) you need to store for correct retrieval - see "Types of Time" in answer.
• Check if your DBMS needs to be shutdown during transition.
• Keep your OS, database and application tzdata files in sync, between themselves and the rest of the world.
• On Servers, set hardware clocks and OS clocks to UTC.
• Use NTP services on all servers.
• If doing historical auditing store both UTC and local time (this allows exact pinpointing of time, as conversion tables will change).
• If using FAT32, remember that timestamps are stored in local time, not UTC.
• When dealing with recurring events (weekly TV show, for example), remember that the time changes with DST and will be different across time zones.

Don't:

• Do not use JavaScript date and time calculations in web applications unless you ABSOLUTELY have to.
• Never trust client datetime. It may very well be incorrect.
• Do not compare client datetimes with server datetimes.

Testing:

• When testing make sure you test countries in the Western and Eastern hemispheres, with both DST in progress and not and a country that does not use DST (6 in total).
• Test all third-party libraries and applications and make sure they handle time zone data correctly.

Reference:

• The detailed timezone tag wiki page on Stack Overflow
• Olson database, aka Tz_database
• IETF draft procedures for maintaining the Olson database
• Sources for Time Zone and DST
• ISO format (ISO 8601)
• Mapping between Olson database and Windows Time Zone Ids, from the Unicode Consortium
• Time Zone page on Wikipedia
• StackOverflow questions tagged dst
• StackOverflow questions tagged timezone
• Dealing with DST - Microsoft DateTime best practices
• Network Time Protocol on Wikipedia

Other:

• Lobby your representative to end the abomination that is DST. We can always hope...
• Lobby for EST