Mensaje de error "fecha: fecha no válida '2016-10-16'"


35

Hoy mi reloj se ajustó automáticamente al horario de verano, y un script de un crontab comenzó a fallar. Eché un vistazo a lo que estaba sucediendo y se mostró el siguiente error, con LC_ALL=C:

fecha: fecha no válida '2016-10-16'

Pensé que sería mejor reiniciar el sistema, pero ahora lo he reiniciado y el error sigue apareciendo:

$ date -d '2016-10-15'
Sat Oct 15 00:00:00 BRT 2016
$ date -d '2016-10-16'
date: data inválida “2016-10-16”
$ date -d '2016-10-17'
Mon Oct 17 00:00:00 BRST 2016

¿Qué podría estar causando esto?


¿Desde qué sistema operativo está ejecutando este comando? No se puede reproducir en Debian 8. Probado con dos locales diferentes : sv_SE.utf8y en_us.utf-8.
maulinglawns

2
¿A qué hora del día (noche) adelanta Brasil los relojes al horario de verano?
techraf

Pensé que todos los países estaban cambiando a una hora tardía, como las 2 de la mañana, donde es menos probable que cause problemas.
njzk2

Respuestas:


57

El problema es que el horario de verano cambió y se envió 1 hora, el 16 de octubre de 2016 en su zona horaria:

$ zdump -v America/Sao_Paulo | awk '/Oct 16/ && /2016/'
America/Sao_Paulo  Sun Oct 16 02:59:59 2016 UTC = Sat Oct 15 23:59:59 2016 BRT isdst=0
America/Sao_Paulo  Sun Oct 16 03:00:00 2016 UTC = Sun Oct 16 01:00:00 2016 BRST isdst=1

Por lo tanto, cualquier momento entre ese día 00:00y 00:59el día se considera inválido en su zona horaria (pero puede ser válido en otros):

$ TZ=America/Sao_Paulo gdate -d '2016-10-16 0:59'
gdate: invalid date ‘2016-10-16 0:59’

$ TZ=Asia/Ho_Chi_Minh gdate -d '2016-10-16 0:59'
Sun Oct 16 00:59:00 ICT 2016

Puede establecer tiempo adicional, que no está en ese rango:

$ TZ=America/Sao_Paulo gdate -d '2016-10-16 1:00'
Sun Oct 16 01:00:00 BRST 2016

Lo anterior es el comportamiento de la fecha GNU.

La fecha BSD no tiene este problema. Si la fecha de entrada no es válida en la zona horaria, se ajustará silenciosamente hacia adelante 1 hora hasta que alcance una hora válida:

$ TZ=America/Sao_Paulo date -j -f '%Y%m%d%H%M' 201610160000
Sun Oct 16 01:00:53 BRST 2016

¿1 hora y 53 segundos?
domen

Entonces, ¿ajustó el tiempo 53 segundos demasiado en el futuro? ¿O entendí mal algo?
domen

1
Aah, tiene sentido; conserva los datos no especificados (en lugar de borrar). Todavía es un poco extraño ya que ajustarse hacia adelante en 00:59:07 sería suficiente en este caso.
domen

Al usar nuestro sitio, usted reconoce que ha leído y comprende nuestra Política de Cookies y Política de Privacidad.
Licensed under cc by-sa 3.0 with attribution required.