DatePickers: trabaja con zonas horarias lähde: Nnabueze Uhiara | Octubre de 2020

Algunos usuarios de la aplicación que creé se quejaron de que cuando eligieron su fecha de nacimiento, la fecha mostrada (y luego enviada al back-end) siempre se apagaba 1 día. Pero funcionó bien para mí.

Le sucedió a varios otros usuarios, por lo que se creó un patrón; debe haber sido un error de mi parte. Como me funcionó bien, tuve que reducir las posibles diferencias entre el entorno de estos usuarios y el mío. Uno atascado: zona horaria. Todos estaban en Canadá.

Sintonizando para encontrar la causa

Traté de reprimirOpara mitigar el error cambiando la zona horaria del dispositivo a Canadá Vancouver (GMT-8). La imagen que dicen vale más que mil palabras, así que aquí hay algunas capturas de pantalla con detalles de mi ruta de depuración:

  1. Cuando elegí 3 de noviembre de 2020 eso fue lo que se devolvió en la devolución de llamada. darse cuenta humanReadableDate se desactiva por 1 día, también que la marca de tiempo devuelta es 1604361600000
¡HumanReadableDate se desactiva en 1 día! Error reproducido 🎊

2. Copié esta marca de tiempo en EpochConverter, ese fue el resultado.

la marca de tiempo muestra la fecha correcta
UX (lo que ve el usuario)

Entonces fue obvio que el error fue introducido por mi dateFormatter. DateFormatter usó la zona horaria del usuario para formatear la marca de tiempo GMT / UTC devuelta por datePicker.

La desviación GMT / UTC en Vancouver es -8 horas. La fecha de la marca de tiempo es 3 de noviembre de 2020, 12:00:00 PM (GMT / UTC). Como Vancouver tiene un retraso de 8 horas GMT / UTC, será el momento 3 de noviembre de 2020 12:00:00 PM menos 8 horas = 2 de noviembre de 2020, 4:00:00 p.m., por lo tanto, la fecha devuelta por dateFormatter.

Arreglo del fallo

Una vez que se encontró la causa, la solución fue bastante fácil: establezca una zona horaria fija (UTC / GMT) que usará dateFormatter. Yo lo hice.

Aquí hay más capturas de pantalla con una descripción detallada del proceso de reparación:

DateFormatter antes de la reparación. La zona horaria no está configurada, por lo que utiliza la zona horaria predeterminada del usuario.

DateFormatter con la corrección aplicada. La zona horaria ahora está configurada en UTC, que utilizará el formateador independientemente de la zona horaria del usuario.

DateFormatter con corrección

Pruebas

La corrección ya se ha aplicado y es hora de probarla. Como de costumbre, compartiré capturas de pantalla de prueba.

Corrección de error verificada: HumanReadableDate ahora muestra la fecha correcta
UX después de aplicar la corrección

También puede escribir pruebas para detectar / proteger de errores la próxima vez.

Deja una respuesta

Tu dirección de correo electrónico no será publicada. Los campos obligatorios están marcados con *