Pregunta ¿Por qué hay una diferencia con la fecha de Unix entre 2 y 3 meses?


¿Cómo es esto posible y cómo lo trato? Estoy haciendo un script de copia de seguridad que depende de Unix date y han descubierto un error interesante:

[root@web000c zfs_test]# date +%y-%m-%d --date='2 months ago'
14-04-01
[root@web000c zfs_test]# date +%y-%m-%d --date='3 months ago'
14-02-28
[root@web000c zfs_test]# date
Sun Jun  1 00:08:50 CEST 2014

16
2018-06-12 02:21


origen


¿Podría ser un error de año bisiesto / 29 de febrero? Improbable en una herramienta como date aunque... - Mark Henderson♦


Respuestas:


Está viendo este comportamiento debido al horario de verano (horario de verano).

Debido a que actualmente se encuentra en el horario de verano, donde su reloj está adelantado una hora, cuando hace tres meses, justo después de la medianoche del 1 de junio, la hora termina siendo una hora "más temprana" porque no era el tercer día de verano. Hace meses.

La documentación de la fecha de GNU sugiere trabajar alrededor de esto utilizando las 12:00 del mediodía y el día 15 del mes como puntos de partida, al solicitar días o meses relativos, respectivamente. Por ejemplo:

date +%y-%m-%d --date="$(date +%Y-%m-15) -3 month"

43
2018-06-12 02:44



gracias. Sí, exactamente "hace 3 meses" a las 01 am: [root@web000c zfs_test]# date +%y-%m-%d --date='3 months ago'  14-03-01  [root@web000c zfs_test]# date  Sun Jun 1 01:00:15 CEST 2014 - Shirker
Doh! Creo que necesito revisar algunas de mis secuencias de comandos ya que sospecho que he pasado por alto esta sugerencia en date uso. - Caleb


Si el tiempo absoluto es su principal preocupación, probablemente es mejor trabajar UTC tal como existe para ese fin. La respuesta de Michael es muy útil para cuando tienes que trabajar dentro del problema, pero generalmente es una buena idea evitarlo por completo donde puedas.

Cuando su sistema no está configurado en UTC de forma predeterminada, la forma más sencilla de pasar la zona horaria es prefijando su comando con TZ Variable ambiental. Esto limita el cambio de zona a un solo comando y evita que la variable se filtre hacia sus comandos subsiguientes.

$ NOW=$(date '+%s')
$ date -d @$NOW
Wed Jun 11 23:44:35 EDT 2014
$ TZ=UTC date -d @$NOW
Thu Jun 12 03:44:35 UTC 2014

Lo que tu no debería hacer es exportar el TZ Esta variable puede hacer que las cosas sean muy confusas para solucionar problemas, como lo demuestra lo siguiente.

$ export TZ=UTC
$ date -d @$NOW
Thu Jun 12 03:44:35 UTC 2014
$ TZ=EDT date -d @$NOW
Thu Jun 12 03:44:35 EDT 2014

14
2018-06-12 03:49





En este año específico en el que su computadora cree que está siendo operada, y en la fecha específica que eligió para una prueba de "hace 1 mes, hace 2 meses y hace 3 meses, sí, es probable que se detecte el 29 de febrero. No siempre un error, pero ..

Ahora, hoy no es 2014-06-01. Inténtalo de nuevo. Establezca la fecha de la computadora para 2013-06-01. Inténtalo de nuevo.
Establecer la fecha de la computadora para el 2014-09-01. Inténtalo de nuevo.


-3
2018-06-12 03:18



Si usted está proporcionando fechas en América MDY formato, uso plase /Es para separar. Aún mejor, ya que somos una comunidad internacional aquí, use las fechas adecuadas de ISO como 2014-09-01. - glglgl