En base a lo que está pasando con el cambio de hora en Argentina y su aplicación en computadoras con unix o linux, apareció esta nota en el blog de Ricardo Goldberger que incluía un comentario del Buanzo que yo contesté más abajo.
Hoy Ricardo publicó una respuesta de Buanzo en la que dice que la única forma razonable de publicar información en tzdata es hacerlo únicamente cuando se esté totalmente seguro de que la información es cierta.
¿Pero quién tiene que estar seguro y quién se ocupa de que la información segura llegue a tiempo a los equipos?
Por suerte, tanto Buanzo como yo usamos sistemas abiertos con lo cual podemos ocuparnos nosotros mismos y cagarnos en el resto del mundo
Supongamos que Olson y Eggert (a quienes no conozco personalmente, pero los respeto por el laburo que hacen y les tengo aprecio porque hacen un laburo que a mi me sirve sin que yo se los pida o les pague por ello), deciden seguir la recomendación que Buanzo (y otra gente en distintas listas y sitios de seguimiento de bugs) recomienda…
Es más, supongamos que Olson y Eggert viven día y noche pendientes de todos los Boletines Oficiales de todos los países (y divisiones políticas en el caso de los países federales como el nuestro) y aparte entienden todos los idiomas (incluídas las versiones legaleese de cada uno de ellos)… en ese caso, podemo suponer que ayer (jueves 16 de octubre) a la mañana (hora argentina) leyeron el Decreto 1693/2008 en el Boletín Oficial y recién ahí modificaron en el tzdata los datos para este verano para toda la Argentina (es lo que dice el Decreto ese) y lo publicaron.
Eso pone (o debería poner) en marcha las actualizaciones de los paquetes en las distintas distros de unix, linux, etcéteras… Por más crítica que consideremos la hora de nuestros servidores, sospecho que los maintainers del paquete tzdata de cada distro no van a dejar todas sus ocupaciones por un update que no consideren crítico ellos (al menos desde el punto de vista de seguridad/intrusión/etc)… con lo cual, la modificación podría aparecer en los repositorios de cada distro con viento a favor durante la semana que viene… o sea, que a partir de las 0 de este domingo, todos los equipos tendrían mal la hora.
Ahora bien, hoy (17 de octubre, un día peronista) a la mañana, resulta que por suerte Olson y Eggert tampoco tienen nada mejor que hacer que leer el Boletín Oficial de Argentina, se encuentran con el Decreto 1705/2008 que dice que doce provincias no van a aplicar el horario de verano… supongamos que en el medio tuvieron la suerte de no leer el Boletín Oficial de Mendoza de ayer jueves 16 de octubre, donde salió la Ley Provincial N° 7.955 que establece que Mendoza utiliza los husos horarios UTC-03:00 y UTC-04:00 y le deja al Poder Ejecutivo Provincial la elección de cuándo usa cuál (no se gasta en aclarar qué piensan hacer esta misma semana, por ejemplo)…
Entonces hoy agarran y vuelven a modificar los datos y sacan una nueva versión de tzdata… y vuelta a comenzar la ronda de updates en el downstream de cada distro… ¿cuándo estarán listas? ¿hoy a la tarde? ¿mañana? ¿el lunes? (ya nos pasamos de las 0 del 19).
La cuestión es que, sea su potestad o no, mientras las autoridades sigan publicando la información oficial con 30 nanosegundos de anticipación a los hechos, la probabilidad de tener mal los datos, por demoras de implementación o por haber hecho una mala presuposición es significativamente cercana a 1.
La gente que está enojada con alguien más que no sean ellos mismos porque el 5 de octubre les cambió la hora de las máquinas, si las cosas se hubieran hecho como ellos dicen, tendrían mal la hora el próximo domingo. ¿Por qué? Porque, claramente, es gente que delega la observación de los cambios de hora en los maintainers de su distribución, y estos maintainers, al menos una vez, demoraron más de quince días en actualizar esa información desde que la tuvieron disponible.
Si los maitainers del tzdata de la distro que estén usando hubiesen sido suficientemente diligentes, para el 5 de octubre ya habrían tenido distribuido el tzdata2008f que se publicó el 15 de septiembre y que corría la fecha del cambio.
Ahora, en el mundo real, Olson y Eggert trabajan de otra cosa y le dedican el tiempo que pueden o quieren a mantener la base de datos tzdata (y el código que la procesa) actualizados… no sé cuántos idiomas hablan además de inglés, pero sospecho que no están leyendo diariamente el Boletín Oficial de la República Argentina. Entonces dependen de que alguien les pase información, intentan ver cuán razonable es y en base a eso deciden incluir una modificación en algún momento.
Si bien el sistema dista de ser perfecto, al menos tiene un buen punto de referencia que es la lista de correo donde se discuten todas estas cosas en forma pública y abierta.
Cualquiera puede participar por más que (como yo) no conozca el funcionamiento interno del paquete tzdata y apenas entienda el formato de la base de datos e inclusive gente que ni siquiera sabe eso, pero puede participar y dar su opinión acerca de la verosimilitud de una información que les concierne y la razonabilidad de aplicar un cambio o no en la base de datos.
La ventaja adicional de participar es que uno se entera de primera mano cuándo hay una actualización de datos y qué contiene y, en base a eso puede decidir aplicarla antes de que llegue a los repositorios de su distribución o puede decidir no aplicarla porque está en desacuerdo (y evitar hacer la actualización una vez que la actualización llegue a los repositorios de la distro).
De lo que yo me quejaba hace unos días no es de que la base tzdata estuviera mal o que la versión en el repositorio de Ubuntu estuviera desactualizada si no de que yo mismo me dejé estar y no estaba leyendo la lista por lo que no me dí cuenta del primer error (de tener el cambio del primer domingo de octubre) ni de que el mismo se había subsanado (mal para algunos) como para ponerme a romper para que el cambio llegue a mi Ubuntu y si no, de última, actualizarlo yo a mano y listo.
La situación hoy es la siguiente: todos los sistemas operativos que estén con la versión tzdata2008f, g, o h y estén en la Ciudad de Buenos Aires o en las Provincias de Buenos Aires, Córdoba, Chaco, Corrientes, Entre Ríos, Formosa, Misiones, Jujuy, Tucumán o San Luis, tienen la hora bien y la van a cambiar (o no cambiar en el caso de San Luis) bien el próximo domingo (suponiendo que entre los Decretos 1693/2008 y 1705/2008 cubren todo y no hay alguna Provincia que decida no acatarlos).
Quienes estén en las Provincias de La Pampa, Catamarca, Chubut, La Rioja, San Juan, Mendoza, Santa Cruz y Tierra del Fuego deberán hacer algo para que no les cambie la hora este domingo 19 de octubre.
Podrían poner a lo bestia la zona horaria Etc/GMT-3 o utilizar America/Argentina/San_Luis (aunque si miran datos viejos, van a estar mal los relojes entre enero y marzo de 2008 ya que San Luis volvió a UTC-3 antes que el resto del país).
La otra variante es utilizar temporalmente la receta que publiqué ayer y actualicé hoy hasta que se actualice tzdata y esa actualización llegue a cada distribución.
Si, tenes toda la razon… pero no deja de ser un problema del paquete tzdata y de hacerle caso a alguien que NI SIQUIERA era argentino respecto de una tematica argentina… si al menos UN argentino (sorry, yo ya no tengo tiempo, viste, y vos obviamente tampoco) hubiera estado ahi, TAL VEZ la safabamos mejor… pero la veo dificil igual. Conozco estas problematicas internas de los paquetes. Te juro que he visto mas de una en esta ultima decada y media de Linux, y van a seguir existiendo. Es por eso que el software libre tiene un lindo mensaje disclaimer: “Este soft se hace disponible con la intencion de que sea util, pero no te damos ninguna garantia.”.
Saludos y ya me aburri de esto :) – Hablemos de my_networks en postfix :P