Enchufe desvergonzado:
Utilice una mejor API de fecha y hora
Las bibliotecas de fecha y hora .NET incorporadas son terriblemente difíciles de usar correctamente. Ellos no le permiten hacer todo lo que necesita, pero no se puede expresar con claridad a través del sistema de tipos. DateTimees un desastre , DateTimeOffsetpuede hacer que piense que en realidad está conservando la información de la zona horaria cuando no lo está, y TimeZoneInfono lo obliga a pensar en todo lo que debería considerar.
Ninguno de estos proporciona una forma agradable de decir "solo una hora del día" o "solo una fecha", ni tampoco hacen una distinción clara entre "hora local" y "hora en una zona horaria en particular". Y si desea utilizar un calendario que no sea el gregoriano, debe pasar por la Calendarclase todo el tiempo.
Por todo esto, estoy construyendo Noda Time , una biblioteca alternativa de fecha y hora construida en un puerto del "motor" de Joda Time , pero con una API nueva (y más sencilla) en la parte superior.
Algunos puntos en los que quizás quiera pensar, que son fáciles de pasar por alto si no los conoce:
- Asignar una fecha / hora local a una en una zona horaria en particular no es tan simple como podría pensar. Una fecha / hora local específica puede ocurrir una, dos veces (ambigüedad) o cero veces (se omite) debido a las transiciones de horario de verano.
- Las zonas horarias varían históricamente, más de lo que
TimeZoneInfogeneralmente está dispuesto a revelar, francamente. (No admite una zona horaria cuya idea de "hora estándar" cambie con el tiempo o que se convierta en horario de verano permanente).
- Incluso con la base de datos zoneinfo, los ID de zona horaria no son necesariamente estables. (CLDR aborda esto; algo que espero apoyar en Noda Time eventualmente).
- Las representaciones textuales de fechas y horas son una pesadilla, no solo en términos de orden, sino también de separadores de fecha, separadores de tiempo y cosas raras como nombres genitivos de meses.
- El comienzo del día no siempre es medianoche; en Brasil, por ejemplo, la transición del horario de verano de primavera mueve el reloj de pared de 11:59:59 p.m. a 1 a.m.
- En algunos casos (bueno, uno que yo sepa), una zona horaria puede obligar a omitir un día entero: ¡el 30 de diciembre de 2011 no ocurrió en Samoa! Sospecho que la mayoría de los desarrolladores probablemente puedan ignorar este, pero ...
- Si va a utilizar un calendario que no sea el gregoriano, tenga cuidado y asegúrese de saber realmente cómo espera que se comporte.
En cuanto a prácticas de desarrollo específicas:
- Piense en lo que realmente está tratando de representar. Espero que el beneficio principal de Noda Time sea obligar a los desarrolladores a elegir entre varios tipos diferentes para representar sus datos. Hágalo bien y todo lo demás será más sencillo.
- Prueba unitaria todo lo que se te ocurra. Eso dependerá exactamente de lo que haga su sistema, por supuesto, pero considere especialmente las diferentes zonas horarias, lo que sucede en las transiciones de horario de verano y, por supuesto, los años bisiestos.
- Aconsejaría inyectar una "interfaz similar a un reloj", un servicio para decir la hora actual, en lugar de llamar explícitamente
DateTime.Nowo DateTime.UtcNow; hace que sea más fácil (¡factible!) realizar pruebas unitarias
- Si está realizando varias operaciones con "ahora", obtenga esa fecha / hora una vez y recuérdelo, en lugar de solicitar repetidamente "ahora"; de lo contrario, el valor podría cambiar de manera desafortunada entre las llamadas.
- "Hacer todo en UTC" tampoco es siempre la respuesta, si quiero saber "¿cuándo exactamente ocurre 'dentro de dos semanas' en mi zona horaria local?" entonces necesito almacenar la fecha / hora local , así como la zona horaria.