Podrías tomar algunas ideas de mi implementación de las fechas de inicio/fin de cupón en el diálogo de Nuevo Cupón en un comercio electrónico en el que estoy trabajando:
Otro ejemplo para demostrar la flexibilidad y cómo evitamos la ambigüedad en los rangos de fechas en la interfaz de usuario:
Detalle técnico: En nuestra aplicación, siempre guardamos las fechas como “timestamp con zona horaria” (postgres), por lo que ninguna configuración de base de datos ni de conexión puede afectar la marca de tiempo real almacenada. Aunque Postgres no lo recomienda, lo hacemos porque ofrece garantías del 100% de la corrección de la fecha en cualquier situación y en cualquier consulta SQL. Puedes operar con zonas horarias de fecha directamente en postgres usando sus funciones de fecha/hora/zona horaria y estar seguro de que funcionará 100% correcto siempre. Confiamos en ello.
Y luego tenemos una configuración de zona horaria para todo tipo de entidades que la necesitan: perfiles de usuario, mercados, cupones, informes para contadores, etc., para que podamos traducir cualquier fecha a cualquier zona horaria sobre la marcha sin dudarlo.
Las principales conclusiones aquí son:
- Siempre almacena la fecha y hora con zona horaria.
- Siempre almacena la preferencia de zona horaria.
- Sé muy explícito sobre las fechas en la interfaz de usuario, no hagas ninguna magia.
- Deja que el usuario vea las fechas reales en la zona horaria elegida antes de hacer clic en “Guardar”.