Seguramente estás seguro de que algunas, si no todas, de estas afirmaciones son verdaderas siempre y en todas partes:
- Siempre hay 24 horas en un día.
- Una semana siempre comienza y termina en el mismo mes.
- Una semana (o mes) siempre comienza y termina en el mismo año.
- El tiempo no tiene principio ni fin.
- Puede haber 28, 29, 30 o 31 días en un mes.
- Hay un año bisiesto cada 4 años.
- En todos los meses, el número de días es siempre el mismo en todas partes.
- El servidor y el cliente siempre tendrán la misma hora.
- Puede calcular fácilmente el número de horas y minutos a partir de algún momento.
- Cada minuto tiene 60 segundos.
Aunque la práctica muestra que es un engaño confiar en la veracidad de estas afirmaciones al desarrollar software. Bueno, está bien, no todos estos puntos son conceptos erróneos . Algunas de las afirmaciones serían ciertas si no fuera por los molestos errores y casos extremos, que se han acumulado una miríada de a lo largo de la historia del software.
Cada minuto tiene 60 segundos y siempre hay 24 horas en un día.
Por ejemplo, en versiones anteriores de KVM en CentOS había un error curioso: un minuto podía durar todo lo que quisiera. El hecho es que KVM no sabía que no se estaba ejecutando en hardware físico, y si el SO de alojamiento suspendía temporalmente la máquina virtual, el reloj virtualizado seguía funcionando desde el momento en que se suspendió . Por ejemplo, si un automóvil se detuvo a las 13:00 y se activó a las 15:00, el reloj del sistema continuará mostrando las 13:00. Como resultado, después de cada pausa, hubo una discrepancia con el tiempo real. Incluso había una tarea cron que se podía configurar para sincronizar el reloj virtualizado con el reloj del hardware. Pero al crear una nueva máquina virtual, fue fácil olvidarse de ella y fue divertido. El error se corrigió más tarde.
Aparte de los errores, también hay un segundo intercalar (extra): se agrega a UTC (Tiempo Universal Coordinado) al final del día el 30 de junio o el 31 de diciembre para compensar la desaceleración gradual de la rotación de la Tierra y la acumulación de la diferencia entre el SI y los días astronómicos - soleado - por días.
En cuanto a la duración del día, el principal enemigo del programador es la transición al horario de verano, que está en algún lugar allí, en algún lugar no, y antes podría cancelarse o introducirse. Este es un gran problema separado con los datos históricos: el horario de verano.
Y si a esto le sumamos el cambio de husos horarios ...
Sobre semanas, meses y años
Pero las historias sobre diferentes períodos de meses y años están asociadas con diferentes cálculos de calendario para diferentes pueblos del mundo. Por ejemplo, el calendario hebreo opera con meses lunares: es decir, el comienzo y el final del mes están ligados a las fases de la luna. ¿Crees que puedes tener esto en cuenta fácilmente agregando un ajuste para Israel con la carga de las fases lunares? No trabajará. En un año bisiesto judío, se agrega un mes adicional . Además, tenga cuidado con las manos, tanto los años simples como los bisiestos en el calendario hebreo pueden tener tres longitudes diferentes . En total, un año puede tener seis duraciones diferentes.de 354 a 383 días. ¿Crees que aquí es donde terminaron las diferencias con nuestro calendario? Donde hay: en el calendario judío, los días tienen diferentes duraciones y se cuentan desde el ocaso hasta el ocaso (formalmente, cuando tres estrellas se hacen visibles en el cielo).
¿Crees que es solo para los judíos que no todo es como en el calendario gregoriano (a la cuestión de la Gran Revolución Socialista de Octubre, que se celebró en la URSS el 7 de noviembre)? En países árabes:
- La semana no comienza el lunes, sino el domingo.
- El fin de semana se considera viernes y sábado, y en algunos países, jueves y viernes. Durante los últimos 10 años, algunos estados han cambiado el fin de semana al viernes y sábado para facilitar el comercio internacional. Y, sin embargo, no todos los países árabes tienen un fin de semana de dos días.
- Los días festivos religiosos dependen de las observaciones del ciclo lunar, por lo que su momento no se puede predecir con precisión.
En cuanto al hecho de que las semanas y los meses pueden terminar el próximo año, esto nuevamente es típico de los países con calendarios lunares y solar-lunares; en ellos, el año nuevo no comienza el 1 de enero. De repente, puede recordar de inmediato a los chinos, cuyo año nuevo comienza en el período del 21 de enero al 21 de febrero según el calendario gregoriano. Y en el calendario etíope, el año nuevo es generalmente el 29 o 30 de agosto, e incluso el número de años que tienen es 8 menos que en el sistema "desde el nacimiento de Cristo".
El servidor y el cliente siempre tendrán la misma hora.
Y aquí hay un hecho interesante, debido a que el tiempo en diferentes computadoras puede no solo no coincidir, sino que incluso el tamaño de la discrepancia puede variar. Cuando Linux se inicia, toma el tiempo actual del hardware y luego lo cuenta hacia atrás, agregando datos del reloj interno del procesador (TSC). Estos relojes pueden ser bastante inexactos. Por ejemplo, debido a la escala del reloj, que cambia dinámicamente la frecuencia TSC. Y si cambia la frecuencia del reloj en el host, todas las cuentas de invitados ni siquiera lo notarán. Si escala la frecuencia TSC en un 50%, el tiempo comenzará a correr el doble de lento. Además, en algunos servidores, el BIOS puede escalar la frecuencia del procesador sin notificar al sistema operativo, lo que también agrega un error. En los procesadores más nuevos, las frecuencias TSC ahora son fijas. Por cierto, Windows no usa TSC, por lo que este sistema operativo tiene otros problemas con la sincronización:)
Puede calcular fácilmente la cantidad de horas y minutos a partir de algún momento
A menos que haya algo como Python en el lenguaje de programación
tzinfo()
, no puede obtener una fecha y hora específicas simplemente agregando horas y minutos a alguna fecha en el pasado. Es necesario tener en cuenta las zonas horarias (y su posible cambio, como ha sucedido más de una vez en la historia), luego tener en cuenta todos los cambios en la transición al horario de verano ... En Windows, esto generalmente es imposible, porque Microsoft proporciona solo el comienzo y el final del año actual. Sorprendentemente, después de tantos parches de manejo de DST, la compañía aún no ha implementado un equivalente de Windows
tzinfo()
. Probablemente no.
El tiempo no tiene principio ni fin
"Su programa nunca necesitará manejar fechas anteriores a 1970". En los sistemas Unix (incluidos Linux e iOS), el tiempo se cuenta en segundos desde las 00:00:00 del 1 de enero de 1970 UTC (hora universal coordinada). Cualquier cosa anterior en Unix ya será tiempo negativo. Además, el tiempo se representa en una expresión entera de 32 bits, y la fecha más temprana posible en los sistemas Unix es el 13 de diciembre de 1901. Y el tiempo Unix "superior" está limitado al 19 de enero de 2038, cuando el número de segundos desde el comienzo de la cuenta regresiva llega a 2 31 , y el sistema puede considerar este número como negativo.
Todo esto es solo una pequeña parte de la gran cantidad de matices y errores a los que se enfrentan los desarrolladores de cualquier producto que requiera mucho tiempo. Seguro que también tienes una historia que contar desde tu experiencia, escribe en los comentarios.