¿Qué define un día?
Los programadores a menudo se centran en las cosas equivocadas al desarrollar nuevas funcionalidades.
Podrías pensar en los datos del backend, la duplicación de código o el rendimiento. Estas cuestiones importan. Pero no son las más importantes.
A menudo cometo este error. Me emociono con patrones inteligentes y código limpio. Empiezo a programar antes de entender completamente cómo el usuario utiliza la funcionalidad. Luego me doy cuenta de que mi código no coincide con el objetivo de negocio.
Tomemos una aplicación de calendario como ejemplo.
Un usuario hace clic en el 1 de marzo para marcar un día festivo. Pero la aplicación marca el 28 de febrero en su lugar. Esto sucede debido a las zonas horarias.
El desarrollador utilizó un objeto Date. Un objeto Date representa un momento específico en el tiempo.
En Tokio, la medianoche del 1 de marzo sigue siendo el 28 de febrero en Londres. Si tu código utiliza métodos UTC para guardar la fecha, el día se desplaza.
El error existe porque la implementación técnica contradice la lógica de negocio.
Un usuario piensa en días. Un usuario no piensa en desfases UTC o marcas de tiempo en milisegundos. Piensa: "Quiero el 14 de marzo".
Si quieres que tu código sea fiable, debes modelar el dominio correctamente.
En un calendario de papel, una fecha es solo un año, un mes y un día. No tiene zona horaria.
Puedes solucionar el error siendo consistente con la hora UTC o la hora local. Pero eso es solo un