Evitar el cambio de hora por fin de horario de verano

[Chano Records Inc.]

Como muchos sabrán, el Gobierno va a extender el horario de verano hasta
fines de marzo, por lo que muchos computadores van a cambiar la hora el
sábado 8 en vez de a fin de mes.

Para evitar esto (en el computador de la casa me da lo mismo, pero no
quiero que sus SMS lleguen con hora incorrecta ;) ) tenía pensado
cambiar la zona horaria de CLT (CLST en realidad) a una que mantenga
GMT-0300 todo el año y luego, el día del verdadero cambio, volverlo a CLT.

Hay alguna manera de modificar los archivos zoneinfo para decirle que
esta año el cambio lo haga el último sábado de marzo y no el segundo y
así no preocuparme de andar cambiando la zona horaria?

(por cierto, son máquinas con RH Enterprise)
Grax.

[Sebastian E. Castro Avila]

Dijo Chano Records Inc. <***@lj.nospam.cl> alguna vez:
CRI> Como muchos sabr?n, el Gobierno va a extender el horario de verano hasta
CRI> fines de marzo, por lo que muchos computadores van a cambiar la hora el
CRI> s?bado 8 en vez de a fin de mes.

CRI> Para evitar esto (en el computador de la casa me da lo mismo, pero no
CRI> quiero que sus SMS lleguen con hora incorrecta ;) ) ten?a pensado
CRI> cambiar la zona horaria de CLT (CLST en realidad) a una que mantenga
CRI> GMT-0300 todo el a?o y luego, el d?a del verdadero cambio, volverlo a CLT.

CRI> Hay alguna manera de modificar los archivos zoneinfo para decirle que
CRI> esta a?o el cambio lo haga el ?ltimo s?bado de marzo y no el segundo y
CRI> as? no preocuparme de andar cambiando la zona horaria?

Estuve leyendo al respecto el fin de semana y esa informacion esta
guardada en el zoneinfo (/usr/share/zoneinfo). Los archivos que
contienen son binarios y traen la informacion de los periodos de
"horario de verano".

Con

zdump -v Chile/Continental | grep 2008

se puede ver la fecha en que la hora cambia.

En California la regla de horario de verano cambio por 2007 y el ajuste
lo hizo la gente que administra la zoneinfo. Despues la actualizacion en
cada maquina se hace por los medios tradicionales (yum update o
similares).


CRI> (por cierto, son m?quinas con RH Enterprise)
CRI> Grax.

Espero te sirva, igual le tengo un ojo a eso porque me pidieron una
manito por ahi.

Saludos

[Pablo Jimenez]

Post by Chano Records Inc.
Como muchos sabrán, el Gobierno va a extender el horario de verano hasta
fines de marzo, por lo que muchos computadores van a cambiar la hora el
sábado 8 en vez de a fin de mes.
Para evitar esto (en el computador de la casa me da lo mismo, pero no
quiero que sus SMS lleguen con hora incorrecta ;) ) tenía pensado
cambiar la zona horaria de CLT (CLST en realidad) a una que mantenga
GMT-0300 todo el año y luego, el día del verdadero cambio, volverlo a CLT.
Hay alguna manera de modificar los archivos zoneinfo para decirle que
esta año el cambio lo haga el último sábado de marzo y no el segundo y
así no preocuparme de andar cambiando la zona horaria?
(por cierto, son máquinas con RH Enterprise)

Parece que la única manera de aplicar un cambio al respecto es
modificando el archivo zoneinfo correspondiente a Sudamérica y hacer
algo del tipo:

# zic -l America/Santiago zoneinfo.modified

donde zoneinfo.modified debiera ser el archivo que obtienes en

http://fxr.googlebit.com/source/share/zoneinfo/southamerica?v=8-CURRENT

Y al parecer la modificación debiera ser eliminar la última regla y
agregar las dos siguientes (asumiendo que el cambio se lleve a cabo
el 29 de marzo):

Rule Chile 2000 2007 - Mar Sun>=9 3:00u 0 -
Rule Chile 2008 only - Mar 29 3:00u 0 -

Estoy con la misma preocupación, pero no he podido armar un laboratorio
y probar si las reglas son las adecuadas. Traté de contactar al SHOA si
tenían info respecto a la fecha del cambio de horario para este año,
pero no recibí respuesta...

Saludos.

[Chano Records Inc.]

Parece que la única manera de aplicar un cambio al respecto es
modificando el archivo zoneinfo correspondiente a Sudamérica y hacer
# zic -l America/Santiago zoneinfo.modified
donde zoneinfo.modified debiera ser el archivo que obtienes en
http://fxr.googlebit.com/source/share/zoneinfo/southamerica?v=8-CURRENT
Y al parecer la modificación debiera ser eliminar la última regla y
agregar las dos siguientes (asumiendo que el cambio se lleve a cabo
Rule Chile 2000 2007 - Mar Sun>=9 3:00u 0 -
Rule Chile 2008 only - Mar 29 3:00u 0 -

Hay que modificar más que eso al parecer. A mi me funcionó con lo siguiente:

Rule Chile 1999 2007 - Oct Sun>=9 4:00u 1:00 S
Rule Chile 2000 2007 - Mar Sun>=9 3:00u 0 -
Rule Chile 2008 only - Mar 30 3:00u 0 -
Rule Chile 2008 max - Oct Sun>=9 4:00u 1:00 S
Rule Chile 2009 max - Mar Sun>=9 3:00u 0 -

Había probado con Mar 29 (*)primero pero ahí hace el cambio un día antes.

Luego de compilarlo lo que me retorna el zdump es:
[***@labo3 zone]# /usr/sbin/zdump -v America/Santiago |grep 2008
America/Santiago Sun Mar 30 02:59:59 2008 UTC = Sat Mar 29 23:59:59
2008 CLST isdst=1 gmtoff=-10800
America/Santiago Sun Mar 30 03:00:00 2008 UTC = Sat Mar 29 23:00:00
2008 CLT isdst=0 gmtoff=-14400
America/Santiago Sun Oct 12 03:59:59 2008 UTC = Sat Oct 11 23:59:59
2008 CLT isdst=0 gmtoff=-14400
America/Santiago Sun Oct 12 04:00:00 2008 UTC = Sun Oct 12 01:00:00
2008 CLST isdst=1 gmtoff=-10800

Para el resto de los años también es correcto.

Por lo menos la compilación funcionó. Mañana voy a hacer pruebas en unas
máquinas a ver como se comporta.

Gracias a ambos por la ayuda.

(*)Si bien aun no sale el decreto correspondiente, los cambios de fecha
siempre son en día sábado, así que lo más seguro es que esa sea la fecha.

[l***@hotmail.com]

Post by Chano Records Inc.

Parece que la única manera de aplicar un cambio al respecto es
modificando el archivo zoneinfo correspondiente a Sudamérica y hacer
# zic -l America/Santiago zoneinfo.modified
donde zoneinfo.modified debiera ser el archivo que obtienes en
http://fxr.googlebit.com/source/share/zoneinfo/southamerica?v=8-CURRENT
Y al parecer la modificación debiera ser eliminar la última regla y
agregar las dos siguientes (asumiendo que el cambio se lleve a cabo
Rule Chile 2000 2007 - Mar Sun>=9 3:00u 0 -
Rule Chile 2008 only - Mar 29 3:00u 0 -

Rule Chile 1999 2007 - Oct Sun>=9 4:00u 1:00 S
Rule Chile 2000 2007 - Mar Sun>=9 3:00u 0 -
Rule Chile 2008 only - Mar 30 3:00u 0 -
Rule Chile 2008 max - Oct Sun>=9 4:00u 1:00 S
Rule Chile 2009 max - Mar Sun>=9 3:00u 0 -
Había probado con Mar 29 (*)primero pero ahí hace el cambio un día antes.
America/Santiago Sun Mar 30 02:59:59 2008 UTC = Sat Mar 29 23:59:59
2008 CLST isdst=1 gmtoff=-10800
America/Santiago Sun Mar 30 03:00:00 2008 UTC = Sat Mar 29 23:00:00
2008 CLT isdst=0 gmtoff=-14400
America/Santiago Sun Oct 12 03:59:59 2008 UTC = Sat Oct 11 23:59:59
2008 CLT isdst=0 gmtoff=-14400
America/Santiago Sun Oct 12 04:00:00 2008 UTC = Sun Oct 12 01:00:00
2008 CLST isdst=1 gmtoff=-10800
Para el resto de los años también es correcto.
Por lo menos la compilación funcionó. Mañana voy a hacer pruebas en unas
máquinas a ver como se comporta.
Gracias a ambos por la ayuda.
(*)Si bien aun no sale el decreto correspondiente, los cambios de fecha
siempre son en día sábado, así que lo más seguro es que esa sea la fecha.

Realice los cambios indicados y funciono bien :) las modificaciones
que realice fueron:
( SO RedHat Ent 5 )
==============================================
[***@mampato lgodoy]# diff zone.orig zone.mod
792c792,795
< Rule Chile 2000 max - Mar Sun>=9 3:00u
0 -
---

Post by Chano Records Inc.
Rule Chile 2000 2007 - Mar Sun>=9 3:00u 0 -
Rule Chile 2008 only - Mar 30 3:00u 0 -
Rule Chile 2009 max - Mar Sun>=9 3:00u 0 -

[***@mampato lgodoy]#
==============================================

Revise cambiando las fechas al Viernes 8 23:58 y al Viernes 29
23:58 y se ve bien :)

Saludos
Luis G.

[Rene Vielma]

Post by Chano Records Inc.

Parece que la única manera de aplicar un cambio al respecto es
modificando el archivo zoneinfo correspondiente a Sudamérica y hacer
# zic -l America/Santiago zoneinfo.modified
donde zoneinfo.modified debiera ser el archivo que obtienes en
http://fxr.googlebit.com/source/share/zoneinfo/southamerica?v=8-CURRENT
Y al parecer la modificación debiera ser eliminar la última regla y
agregar las dos siguientes (asumiendo que el cambio se lleve a cabo
Rule Chile 2000 2007 - Mar Sun>=9 3:00u 0 -
Rule Chile 2008 only - Mar 29 3:00u 0 -

Rule Chile 1999 2007 - Oct Sun>=9 4:00u 1:00 S
Rule Chile 2000 2007 - Mar Sun>=9 3:00u 0 -
Rule Chile 2008 only - Mar 30 3:00u 0 -
Rule Chile 2008 max - Oct Sun>=9 4:00u 1:00 S
Rule Chile 2009 max - Mar Sun>=9 3:00u 0 -
Había probado con Mar 29 (*)primero pero ahí hace el cambio un día antes.
America/Santiago Sun Mar 30 02:59:59 2008 UTC = Sat Mar 29 23:59:59
2008 CLST isdst=1 gmtoff=-10800
America/Santiago Sun Mar 30 03:00:00 2008 UTC = Sat Mar 29 23:00:00
2008 CLT isdst=0 gmtoff=-14400
America/Santiago Sun Oct 12 03:59:59 2008 UTC = Sat Oct 11 23:59:59
2008 CLT isdst=0 gmtoff=-14400
America/Santiago Sun Oct 12 04:00:00 2008 UTC = Sun Oct 12 01:00:00
2008 CLST isdst=1 gmtoff=-10800
Para el resto de los años también es correcto.
Por lo menos la compilación funcionó. Mañana voy a hacer pruebas en unas
máquinas a ver como se comporta.
Gracias a ambos por la ayuda.
(*)Si bien aun no sale el decreto correspondiente, los cambios de fecha
siempre son en día sábado, así que lo más seguro es que esa sea la fecha.

Hola..

tengo una duda. Fíjate que hago:

$ zdump -v Chile/Continental | grep 2008
Chile/Continental Sun Mar 9 02:59:59 2008 UTC = Sat Mar 8 23:59:59
2008 CLST isdst=1
Chile/Continental Sun Mar 9 03:00:00 2008 UTC = Sat Mar 8 23:00:00
2008 CLT isdst=0
Chile/Continental Sun Oct 12 03:59:59 2008 UTC = Sat Oct 11 23:59:59
2008 CLT isdst=0
Chile/Continental Sun Oct 12 04:00:00 2008 UTC = Sun Oct 12 01:00:00
2008 CLST isdst=1
$su
# zic -l America/Santiago zoneinfo.modified
zic: Can't open zoneinfo.modified: No such file or directory
# touch zoneinfo.modified
# zic -l America/Santiago zoneinfo.modified
# cat zoneinfo.modified
#
# echo "hoo! .. mi 'zoneinfo.modified' está vacío"
hoo! .. mi 'zoneinfo.modified' está vacío
#

por que el archivo 'zoneinfo.modified' queda vacío ??

gracias.

[Andres Pereira]

Post by Pablo Jimenez
$su
# zic -l America/Santiago zoneinfo.modified
zic: Can't open zoneinfo.modified: No such file or directory

Bajaste el archivo de zonas ? Parece que no ...

Saludos,

--
Andres Pereira

[Rene Vielma]

Post by Andres Pereira

Post by Pablo Jimenez
$su
# zic -l America/Santiago zoneinfo.modified
zic: Can't open zoneinfo.modified: No such file or directory

Bajaste el archivo de zonas ? Parece que no ...
Saludos,

Pequeño detalle..
Solucionado

gracias..

[Yi Ci]

Post by Chano Records Inc.
Como muchos sabrán, el Gobierno va a extender el horario de verano
hasta fines de marzo, por lo que muchos computadores van a cambiar la
hora el sábado 8 en vez de a fin de mes.
Para evitar esto (en el computador de la casa me da lo mismo, pero no
quiero que sus SMS lleguen con hora incorrecta ;) ) tenía pensado
cambiar la zona horaria de CLT (CLST en realidad) a una que mantenga
GMT-0300 todo el año y luego, el día del verdadero cambio, volverlo a CLT.
Hay alguna manera de modificar los archivos zoneinfo para decirle que
esta año el cambio lo haga el último sábado de marzo y no el segundo y
así no preocuparme de andar cambiando la zona horaria?
(por cierto, son máquinas con RH Enterprise)
Grax.

Recomendación.

Levante un NTP local y que se cuelgue de la UTFSM, santo remedio.

Luego tus maquinas se cuelgan del local. Puede ser hasta un nodo virtual
con vmware o Xen

[Chano Records Inc.]

Post by Yi Ci

Post by Chano Records Inc.
Como muchos sabrán, el Gobierno va a extender el horario de verano
hasta fines de marzo, por lo que muchos computadores van a cambiar la
hora el sábado 8 en vez de a fin de mes.
Para evitar esto (en el computador de la casa me da lo mismo, pero no
quiero que sus SMS lleguen con hora incorrecta ;) ) tenía pensado
cambiar la zona horaria de CLT (CLST en realidad) a una que mantenga
GMT-0300 todo el año y luego, el día del verdadero cambio, volverlo a CLT.
Hay alguna manera de modificar los archivos zoneinfo para decirle que
esta año el cambio lo haga el último sábado de marzo y no el segundo y
así no preocuparme de andar cambiando la zona horaria?
(por cierto, son máquinas con RH Enterprise)
Grax.

Recomendación.
Levante un NTP local y que se cuelgue de la UTFSM, santo remedio.
Luego tus maquinas se cuelgan del local. Puede ser hasta un nodo virtual
con vmware o Xen

No sirve. El NTP lo que hace es sincronizar la hora y luego aplicar
la corrección de zona horaria en base a lo que esté configurado en la
máquina. Es esto último lo que falla, ya que hasta el 08/03 el ajuste es
-0300 respecto a UTC y después es -0400. De hecho puedo usar un servidor
NTP de Japón y voy a estar igual de sincronizado que si uso uno chileno.

[Pablo Jimenez]

Post by Yi Ci

Post by Chano Records Inc.
Como muchos sabrán, el Gobierno va a extender el horario de verano
hasta fines de marzo, por lo que muchos computadores van a cambiar la
hora el sábado 8 en vez de a fin de mes.
Para evitar esto (en el computador de la casa me da lo mismo, pero no
quiero que sus SMS lleguen con hora incorrecta ;) ) tenía pensado
cambiar la zona horaria de CLT (CLST en realidad) a una que mantenga
GMT-0300 todo el año y luego, el día del verdadero cambio, volverlo a CLT.
Hay alguna manera de modificar los archivos zoneinfo para decirle que
esta año el cambio lo haga el último sábado de marzo y no el segundo y
así no preocuparme de andar cambiando la zona horaria?
(por cierto, son máquinas con RH Enterprise)
Grax.

Recomendación.
Levante un NTP local y que se cuelgue de la UTFSM, santo remedio.
Luego tus maquinas se cuelgan del local. Puede ser hasta un nodo virtual
con vmware o Xen

NTP sincroniza la hora en UTC. El cambio de hora se realiza a nivel
local en cada máquina, de acuerdo a lo que definen las reglas de zoneinfo.
Así que el servidor NTP que recomiendas no servirá de mucho este sábado...

Ve las otras respuestas en el thread y la solución propuesta por Chano.

Saludos.