Il buon schema qui è quello di convertire sempre da e verso UTC su alcuni (e sempre lo stesso) bordo. Ad esempio, è possibile archiviare i dati in UTC, è possibile eseguire la maggior parte della logica dell'intervallo in UTC e l'unica volta che è necessario convertirsi è quando si visualizzano o si inseriscono valori (ad esempio, nel browser Web).
Beh, potrebbero esserci delle eccezioni a questa regola. Se il tuo modello di dominio funziona con concetti come "night" e "day", allora nel modello stesso hai bisogno di conoscere il fuso orario dell'utente e nelle funzioni che si occupano di calcoli specifici del fuso orario usa quella conoscenza. Devi scoprire attentamente tutti i casi in cui il fuso orario può influenzare le decisioni della logica di dominio.
Un altro approccio consiste nell'utilizzare sempre i dati datati con timezone. Tuttavia, potrebbe essere più difficile in quanto dipende dalle capacità delle librerie che si stanno utilizzando e anche se parte del proprio sistema utilizza datazioni ingenue (ovvero ignorando i fusi orari). Mescolare questi può essere pericoloso.
La durata è menzionata nella domanda, ma non riesco a vedere come possa influenzare il problema del fuso orario. Inoltre, quando l'ora legale passa all'ora solare, ci sono due ore, che sono esattamente le stesse se non si conosce l'ora UTC o l'indicatore dell'ora legale. Quindi, la memorizzazione della durata può essere un modo un po 'migliore per evitare l'ambiguità in quell'ora particolare dell'anno, se per qualche motivo non puoi fare tutto in UTC.