Buena vibra desde Morelia. Un like desde antes de ver, más problemas de que preocupar, importante aporte a la comunidad; no conocía esté problema el nuevo y2k. Más videos de cultura informática.
gran trabajo Fer, estaría interesante saber tu opinión sobre los modelos de LLM nuevos o las actualizaciones de Open AI. Supongo también que habrá gente que le interese saber del tema del ecosistema empresarial en tecnología. Saludos desde Monterrey, México✌🏻
Lo único que puedo comentar sobre este video es: Eso que? Lo diré de esta manera, no sé por qué me suena tan familiar, como cuando se dijo que en el año 2000 precisamente por la forma En qué se estaban los relojes de todas las computadoras, en ese momento iban a reiniciarse todas e íbamos a volver a la edad de las cavernas, y oh sorpresa! No pasó nada! A Eso me suena esto último que escribiste, Y si bien es cierto era un problema real, cuya solución no fue nada fácil, fue un problema que se pudo resolver totalmente, aún siendo global, y como tú mismo dices ya están trabajando en eso, Así que perdón por no tomar mucho en serio este problema, PERO NO PASA NADA! Gracias por el video y saludos
@@tensoescalar1 De hecho ya está resuelto. En los sistemas UNIX (es decir todos los sistemas operativos de uso actual que no son Windows o su clon ReactOS) la fecha es contabilizado en el formato de tiempo UNIX que significa que se cuenta utilizando una variable de número entero con signo la cúal empieza a contar desde el 1 de enero de 1970 (cuando se lanzó al mercado el primer sistema operativo UNIX), el problema siendo que en sistemas de 32bits la cantidad de segundos que esa variable puede almacenar hasta que la variable salte al otro extremo de la misma es de 2 a la potencia de 32 menos 1 lo que significa que al llegar al 19 de enero del 2038 el reloj salta al 13 de diciembre del 1901. La solución fué de usar para esa función una variable de 64bits con signo la que tiene mucha más capacidad por lo que la fecha no gira sino hasta el año 8000. Esta solución ya ocurre de serie en sistemas de 64bits y es posible de implementar con coste de desempeño en sistemas de 32bits
seguro que en las finanzas va a haber un gran problema porque la mayoría son sistemas legacy demasiado grandes que son costosos de actualizar y por eso no se lo hace, en el 2038 igual habrán de esos sistemas y muchos más...
Chale, muchos sistemas embebidos de hoy van a caer a la lona en 14 años jaja (nota, muchos de estos salen con garantia de soporte por 10 años, es decir hay que ver que pasa en 4 años y esas garantias)
@@feregri_no Todo depende de la representación interna que se haga del Epoch time en la máquina (32 o 64 bits) y del compilador o interprete. Máquinas de 32 bits apenas hay, hace ya muchos años que hasta los procesadores de los móviles son de 64 bits. Y en cuanto a los compiladores/interpretes depende del tamaño de bits que utilicen por defecto, aunque se pueden adaptar a las necesidades para lo que quieras representar. Para muestra, un código en python, no es necesario esperar a 2038 para ver como todo va a "crashear"😵💫 import calendar , time future_time = calendar.timegm(time.strptime('2040-05-05 12:34:00', '%Y-%m-%d %H:%M:%S')) print(future_time) print(time.strftime('%Y-%m-%d %H:%M:%S', time.gmtime(future_time))) Resultado: 2219834040 2040-05-05 12:34:00 ...... Vamos que no creo que haya que levantar las alarmas como dice otro comentario más abajo. Es posible que algo falle, algún dispositivo 32 bits y sin mantenimiento, pero no creo que haya que entrar en pánico...
Buena vibra desde Morelia. Un like desde antes de ver, más problemas de que preocupar, importante aporte a la comunidad; no conocía esté problema el nuevo y2k. Más videos de cultura informática.
Siempre se aprende algo nuevo :)
Me hizo recordar el problema del 2000. Al final, no pasó gran cosa. Así que confío en que esta vez también sabremos y podremos resolver antes 😉
No pasó gran cosa porque se trabajo duro para que no pasara gran cosa
Exacto @huss31mx
Miles de sistemas financieros aun estan desarrollados usando Cobol, hay que investigar si ya estan previendo esto gracias por este video
gran trabajo Fer, estaría interesante saber tu opinión sobre los modelos de LLM nuevos o las actualizaciones de Open AI. Supongo también que habrá gente que le interese saber del tema del ecosistema empresarial en tecnología. Saludos desde Monterrey, México✌🏻
A ver si grabo algo rápido
Lo único que puedo comentar sobre este video es: Eso que?
Lo diré de esta manera, no sé por qué me suena tan familiar, como cuando se dijo que en el año 2000 precisamente por la forma En qué se estaban los relojes de todas las computadoras, en ese momento iban a reiniciarse todas e íbamos a volver a la edad de las cavernas, y oh sorpresa! No pasó nada!
A Eso me suena esto último que escribiste, Y si bien es cierto era un problema real, cuya solución no fue nada fácil, fue un problema que se pudo resolver totalmente, aún siendo global, y como tú mismo dices ya están trabajando en eso, Así que perdón por no tomar mucho en serio este problema, PERO NO PASA NADA!
Gracias por el video y saludos
En el 2000 no pasó nada porque la gente se puso a trabajar para resolver el problema, no es que no pasó nada porque no hubo problema.
@@feregri_no es cierto, y es lo mismo que pienso que va a pasar ahora
@@tensoescalar1 De hecho ya está resuelto. En los sistemas UNIX (es decir todos los sistemas operativos de uso actual que no son Windows o su clon ReactOS) la fecha es contabilizado en el formato de tiempo UNIX que significa que se cuenta utilizando una variable de número entero con signo la cúal empieza a contar desde el 1 de enero de 1970 (cuando se lanzó al mercado el primer sistema operativo UNIX), el problema siendo que en sistemas de 32bits la cantidad de segundos que esa variable puede almacenar hasta que la variable salte al otro extremo de la misma es de 2 a la potencia de 32 menos 1 lo que significa que al llegar al 19 de enero del 2038 el reloj salta al 13 de diciembre del 1901. La solución fué de usar para esa función una variable de 64bits con signo la que tiene mucha más capacidad por lo que la fecha no gira sino hasta el año 8000. Esta solución ya ocurre de serie en sistemas de 64bits y es posible de implementar con coste de desempeño en sistemas de 32bits
Saludos gracias exelente aporte
😄
seguro que en las finanzas va a haber un gran problema porque la mayoría son sistemas legacy demasiado grandes que son costosos de actualizar y por eso no se lo hace, en el 2038 igual habrán de esos sistemas y muchos más...
Finanzas es justamente en donde mucho del esfuerzo se está poniendo para prevenir este problema.
Esto se parece a la leyenda de john titor, quien retrocede a 1975 desde el año 2036 a reparar un problema con todas las computadoras
Uff, un video sobre eso estaría muy bien.
esto ya no paso hace poco?
En el 2000 se esperaba algo parecido
Chale, muchos sistemas embebidos de hoy van a caer a la lona en 14 años jaja (nota, muchos de estos salen con garantia de soporte por 10 años, es decir hay que ver que pasa en 4 años y esas garantias)
🥶 se va a poner buena la cosa
El epoch cero no será 1901, será 1-1-1970.
El 0 si, pero el -2,000,000,000 no
@@feregri_no Todo depende de la representación interna que se haga del Epoch time en la máquina (32 o 64 bits) y del compilador o interprete. Máquinas de 32 bits apenas hay, hace ya muchos años que hasta los procesadores de los móviles son de 64 bits. Y en cuanto a los compiladores/interpretes depende del tamaño de bits que utilicen por defecto, aunque se pueden adaptar a las necesidades para lo que quieras representar. Para muestra, un código en python, no es necesario esperar a 2038 para ver como todo va a "crashear"😵💫
import calendar , time
future_time = calendar.timegm(time.strptime('2040-05-05 12:34:00', '%Y-%m-%d %H:%M:%S'))
print(future_time)
print(time.strftime('%Y-%m-%d %H:%M:%S', time.gmtime(future_time)))
Resultado:
2219834040
2040-05-05 12:34:00
...... Vamos que no creo que haya que levantar las alarmas como dice otro comentario más abajo. Es posible que algo falle, algún dispositivo 32 bits y sin mantenimiento, pero no creo que haya que entrar en pánico...
Guaaaay:)
:)