David,

missing DST support is a known limitation and I already worked out requirements to switch using .Net timezones (which had been added in .Net 3.5, we are now able to use). Thus said, it is just a matter of spare time to find for implementing it  into the core framework.

David,

.Net Time Zones base on Windows time zones, this service saves us from the need to integrate the tz database. .Net Time Zones differ from Standard Time Zones (STZ) by identifying just a STZ subarea with same DST settings, idenified by an internal ID and a couple of city names for the user. 

One major problem switching DNN to  .Net TZ will be the migration of existing TZ values stored in the database, because each current TZ value (in fact, it is standard offset in minutes disregarding DST) will be substituted by multiple new IDs.

What are the caveats for module developers? make sure to store values using UTC and convert before displaying/ just after data has been entered, according to current user TZ offset from user profile. If you need to add proprietary DST support, add an additional property to user profile and other TZ settings - but be aware, it won't be taken into account during DNN upgrade, when DST gets supported. Stand away from using UserTime class, there are a number of misnamed methods included. I will post more information about this subject, as soon as it's been decided and implemented.