Resumen

  • El aviso de APNIC fija una ventana de seis horas para actualizar Kubernetes el 21 de octubre; la página de estado muestra el intervalo UTC equivalente.
  • El feed iCalendar enlazado registra el mismo evento desde el 19 de octubre a las 22:30 UTC, un día antes. La diferencia no demuestra una caída ni un impacto real.

Un mismo trabajo, dos fechas de inicio

El aviso de servicio de APNIC programa una actualización de un clúster de Kubernetes para el miércoles 21 de octubre de 2026, de 08:30 a 14:30 (UTC+10). Advierte que el ciclo de los nodos podría causar interrupciones breves. Las seis horas describen la ventana de trabajo, no seis horas de indisponibilidad para cada servicio mencionado.

La página pública Services Status muestra el mismo evento desde el 20 de octubre a las 22:30 UTC hasta el 21 de octubre a las 04:30 UTC. Es el mismo intervalo de seis horas del aviso. El feed iCalendar no coincide: el evento titulado “Kubernetes upgrade” enlaza en su descripción al mismo aviso del 21 de octubre, pero fija DTSTART;TZID=UTC:20261019T223000 y DTEND;TZID=UTC:20261020T043000.

Convertidas a UTC+10, esas marcas sitúan el inicio el 20 de octubre a las 08:30 en Brisbane y el final a las 14:30: exactamente un día antes que el aviso y la página de estado. El feed indica de forma explícita que las horas están en UTC; leerlas como hora local de Brisbane no explica las 24 horas de diferencia. El título, la duración de seis horas y el enlace al aviso muestran que los registros se refieren al mismo trabajo previsto.

Para un equipo que importa el feed a su calendario de cambios, la diferencia es práctica: el feed presenta otro día que el aviso y la página de estado de APNIC. Las fuentes no permiten saber qué fecha espera APNIC que sigan los operadores, si alguien utilizó la entrada adelantada ni si habrá interrupciones. En los registros consultados, el trabajo todavía está pendiente.

Fuentes

La comparación usa el aviso de servicio de APNIC, su página pública de estado y su feed iCalendar.