Una viñeta de xkcd que describe el formato correcto para las fechas.
Portada
mis comunidades
otras secciones
Comentarios
Aunque el texto alternativo de la viñeta nos muestra paradójicamente que muchas veces no se usa y resulta confuso.
Día, mes y año. Lo que diga el estándar me suda el escroto.
#2 Eso es porque no te toca ordenar archivos de registro con nombre de fecha.
En el curro siempre uso el formato AAAAMMDD.
A partir de ahora pondré también los guiones como separador .
#3 Cualquier sistema que se precie trabaja de modo interno segun este standard.. y luego te muestra la informacion como te salga del nardo, pero ordenada segun el standard.
Es por eso que en una tabla de fechas ordenadas en dd-mm-aa vemos
01-10-22
02-10-22
01-11-22
en lugar de
01-10-22
01-11-22
02-10-22
Ademas ordena de manera correcta los archivos con inicio de nombre en numeros romanos sin considerarlos letras y otros detalles como los meses de 1 o 2 numeros (01-12 ó 1-12).
Pues yo creo que MMXXIII-II-XXVII es válido, solo que los números se escriben con unos símbolos diferentes. #SPQR
A ver, imaginad que tenéis que enviar una fecha codificada con vuestra máquina enigma... ¿Cómo lo hacéis si no tiene números?
#4: A mi lo de poner los años con dos cifras no me gusta... no sé si es que llegue a conocer el cambio de milenio...
#5 ¿"Siete de Marzo del dos mil dieciséis"?
#7: En realidad sería "sietedemarzodedosmildieciseis", porque no tenía espacios.
#4 Cualquier sistema que se precie trabaja de modo interno segun este standard
Uf, no. Esto es un estándar de representación externa, no interna.
Internamente podrías por ejemplo representar la fecha como el número de segundos transcurridos desde 1970-01-01 a las 00:00 UTC, como se hace en Unix.
#8 Touchè.
*(y veo que me has ahorrado la humillación de mencionar las mayúsculas y las tildes)
#9 Quiero decir que windows internamente trabaja asi.. ya se que unix usa ese formato.. y cada uno con us base de datos el que mas le plazca..
#11 No. Querrás decir en todo caso que Windows se acuerda de "la fecha verdadera", pero no que la guarda internamente en este formato concreto. Insisto en que este formato es de representación externa, no interna.
Lógicamente, si te acuerdas de la fecha verdadera, puedes ordenar archivos "por orden de fecha verdadera", pero no hay ninguna razón por la que esa "fecha verdadera" tenga que estar guardada internamente en el formato ISO como una cadena de caracteres.
#2 ¿También al escribir números pones primero las cifras menos significativas?
AAMMDDhhmmss AC/DC o +/-
#14 AAAA, sino 98 es mayor que 09. 1998, 2009.
Yo siempre uso DD-MM-AAAA y me pueden comer la poll... el resto. para ordenar se usa el formato unix no me jedáis.
Para mi las únicas aberrantes de uso común son las que intercambian mes y día dejando cualquier peso desordenado o el uso de letras, pero vamos, que tienen razón, pero estoy seguro que la génesis de la queja es por la fecha como la usa un estadounidense.
#13 Significativa para quién? o para qué?
Si hablas de la fecha del día de la independencia de Cuba, lo mas significativo es el año, pero si hablas de que día hemos quedado para cenar con Antonio, lo mas significativo es el día del mes.
#2 Idem.
#6 Me pasa lo mismo. Yo viví el síndrome Y2K y estuve veinticuatro horas con un salto en el estómago. Afortunadamente todo fue bien, pero la espera se me hizo eterna. Supongo que a muchos les habrá sucedido algo por el estilo.
#4 hola
En mi vida he visto un listado de archivos escritos ddmmaaaaXXX que el sistema los listara correctamente ordenados cronológicamente.
Obviamene después estaremos en estas https://xkcd.com/927/
#2 algo parecido me dijo un ex-componente del equipo entre algunas otras lindezas, y el tiempo lo puso en su sitio
de una patada en el culo, claro, y sin posibilidades de volver a ninguna otra empresa del grupo 
#18 https://es.wikipedia.org/wiki/Cifras_significativas
Da mas información saber el año que ocurrió un evento que solo el día.
#18
https://es.wikipedia.org/wiki/Cifras_significativas
#5 hola
A ver, imaginad que tenéis que enviar una fecha codificada con vuestra máquina enigma... ¿Cómo lo hacéis si no tiene números?
El típico problema de tener que enviar números en una enigma, que levante la mano al que no le haya pasado la última semana %)
#16 hola
Te comeremos lo que quieras pero no tendrás los ficheros ordenados %)
#21 sisisisisi.... Cuando le das a la columna de fecha de modificación
#28 hola
Aahhhhh %) suponiendo que ese dato sea significativo, porque pueden ser datos de una fecha descargados en otra o editados a posteriori...
A mi el formato AAAA-MM-DD no es que me encante, pero me parece correcto por tener un orden lógico descendente (de mayor a menor); el que me gusta es el DD-MM-AAAA que me parece correcto porque tiene un orden lógico ascendente (de menor a mayor); y el que no soporto es el de los retrasados de los angolsajones de MM-DD-AAAA que no tiene ni lógica, ni sentido, ni ostias. Putos anglosajones, son retorcidos hasta pa eso.
#26 iba a enviar este mensaje codificado con la enigma pero me ha pillado en el baño y dije "bah, asi mismo, que todo el mundo lo lea".
#20: Yo lo viví, pero en el instituto, pero desde entonces dejé de escribir las fechas recortadas.
#22 jajajajaja! Como en el curro, cuando el equipo de programadores acordamos una nuevo criterio para hacer X. Terminas encontrando N+1 formas de ver las cosas en el codigo de la aplicacion porque no se modifica lo anterior porque cuesta mucho.
El de AAMMDD es el más cómodo para ordenar listas de documentos y poder tener un orden cronológico.
El cristo de poner orden o descifrar un expediente con 40+ archivos y carpetas sin saber que va antes o que va después no tiene precio...
#1 relacionado
#32 Podemos poner tres números y ya atrasamos el problema hasta el año 3000, pero nos ahorraremos gigas hasta entonces.
#7 Pero tampoco tenía guiones ¿En MMXXIIIIIXXVII cómo sabrías si es marzo de 2022 o febrero de 2023? Y además usaban la X como punto y, en ocasiones, como espacio, lo cual añadiría aún más confusión.
Los alemanes, en Enigma, codificaban los números cifra a cifra, 2023-02-27 sería: ZWEINULLZWEIDREINULLZWEIZWEISIEBEN. Desconozco si representaban así las fechas (aunque lo dudo), pero la hora sí la representaban de ese modo. P. ej., las 10:30 serían las EINNULLDREINULL.
#10 Lo que no tenía era minúsculas
#22 Lo bueno de los estándares es que hay muchos donde elegir
#4 Yo a las fotos les pongo la fecha en el nombre del archivo y es muy práctico tenerlas en formato aaaammdd.lugar
Es exactamente como mi móvil imprime las fechas en las fotos.
Cuando trabajas con documentos de muchos años es el más cómodo, además que están ordenados
Yo uso YYYYMMDD_HHMM y ya no soporto otra cosa
#18 LSN, less significative number, es un concepto matemático que indica orden de magnitud, no importancia subjetiva. En un patrón "fecha", día es el dato menos significativo porque su orden de magnitud es inferior a los de mes y año.
#4 como complemento a la primera frase de tu comentario, la Administración tiene la sádica costumbre de no tener un formato estandarizado de fechas en sus formularios lo que da más de un quebradero de cabeza a quien se enfrenta a uno por primera vez porque no deja avanzar ni presentar el modelo si no está en el formato correcto y la fecha no suele ser de los campos que vengan explicados en la ayuda porque se sobreentiende que todo el mundo sabe ponerla correctamente.
Así unas veces es DD/MM/AA, otras veces DD-MM-AA y otras veces hay un campo AAAA separado de otro que puede ser DD/MM o DD-MM
#13 en x86? Siempre.
La ISO8601 también determina cual es la primera semana del año, que también da para historias...
Aprovecho el espacio disponible:
- Cuando me autentifico para comentar me aparece la portada, no la noticia que estoy leyendo.
- Cuando envío el comentario, éste no aparece publicado (el formulario de envío está encima del primer comentario).
- El refresco hace aparecer el formulario de envío al final del último comentario y entonces sí que funciona.
Pero debo ser rancio, supongo.
#1 #3 #4 En Suecia es la forma estándar de escribir una fecha en documentos oficiales.
https://en.wikipedia.org/wiki/Date_and_time_notation_in_Sweden
#FreeAssange
#12 Muy bien apuntado
De hecho, en windows se miden los intervalos de 1x10^-7 segunds desde el 1 de enero de 1601 a las 0:00:00 (el motivo... ni idea, pero creo firmemente que para generar estrés a los admins que quieran integrar Linux/Unix con AD via LDAP e intentar mapear en nlscd timestamps de password expiry, etc. u_u)
https://en.wikipedia.org/wiki/Epoch_(computing)
Luego, ya que #9 menciona BBDD, en Oracle es... bueno, no exactamente como uno podría esperar, supongo.
https://oracle-base.com/articles/misc/oracle-dates-timestamps-and-intervals#date
#45 Been there, felt that pain u_u (lo de la semana del año, lo de comentarios en mnm... no he notado nada raro aún siendo tb rancio)
#47 Podria ser por que antes de esa fecha habria que saber si es si el dia es gregoriano o juliano.
https://es.wikipedia.org/wiki/Calendario_gregoriano
En sistemas de fichero no sera necesariio, pero en algun sitio se necesitaran fechas antiguas.
Es comentario lo escribí en 20220402T161230Z
y también es ISO 8601 válido.
Es más, es mucho más correcto, incluye hasta segundo (suficiente) y zona horaria (UTC).
Es lo que usamos para algunos ficheros.
#30 hola
El formato americano imagino que hereda la manera de escribir que tienen ellos poniendo el mes por delante, pero que llevado al terreno tecnológico no tiene ningún sentido porque no mantiene ninguna estructura lógica de más a menos o de menos a más, como bien dices.
#14 hola
Importante lo de AC/DC, sobre todo si has bajado también a mmss %)
#43 hola
La administración española que tenga un formulario aaaammdd es porque tiene a un desarrollador que no se ha fijado que el resultado está mal, porque en España aaaammdd no es de uso común (ni en ningún lado, otro tema es cómo organizas ficheros, nada que ver con formularios de usuario).
#23 hola
Hasta que te lo encontraste en MNM años después defendiendo exactamente lo mismo %)
#3 Yo utilizo solo dos cifras para el año, utilizar 4 me parecía demasiado optimista.
#20 Yo empecé a trabajar en sistemas en el 99 y me pasé un año entero aplicando parche tras parche a todo tipo de sistemas, y automatizando las instalaciones. Suficiente para no volverá poner un año con dos dígitos en lo que me queda de vida.
#2 23-12-22 o 22-12-23, a que fecha me refiero?
#54 No creo, este no es holandés...
#20 Yo lo viví y no me asustó para nada. Mis programas estaban hechos desde el principio para poder soportar cualquier fecha.
#18 eso explícaselo a los yankis, que ponen primero el mes, luego el día y luego el año, para ellos hoy estamos en abril el segundo de veinte ventidos.
#9 Uf, no. Esto es un estándar de representación externa, no interna.
Interna también. Incluso el viejo dbase guardaba los datos así. SQL en el formato de fecha también.
#57 hola
En España a ninguna estandarizada porque normalmente se usan barras pero todos interpretaríamos dd-mm-aa porque es el orden habitual.
En un contexto americano se perderían porque ya no sigues su standard y, efectivamente, que no uses aaaa ayuda todavía menos %)
#16 Aja... tu usa formato unix, a mi déjame con iso8601. En el 2037 estarás muy ocupado y yo no...
#55 Con 2 cifras lo veo más lioso cuando se dan algunas circunstancias.
Yo me entero, pero mis compañeros pueden dudar
22-03-21 puede dar lugar a dudas. 2022-03-21 está claro como el agua.
La fecha de mi boda en el anillo la tengo en ese formato. No digo más (y no, no es coña )
#59 En aquella fecha mi aplicación contable estaba hecha con Clipper --luego la migré a Delphi -- . Clipper guardaba las fechas en el formato AAMMDD, así que imagina cómo estabamos.
#56 Entonces el efecto 2000 no tuvo lugar por el trabajo previo o fue una fake news?
#51 Si, el conocido como formato americano, pero por mi experiencia, en muchos países de ascendencia anglosajona, se usa ese formato.
#66 Clipper era compatible con dbase, y dbase guardaba el año en 4 dígitos... a no ser, claro, que no usaras formatos de fecha propios del clipper sino strings hechos a mano.
#2 Te digo lo de #3: cuando tienes que ordenar archivos por fecha en el nombre de archivo, esa forma tuya no funciona.
#67 por ambas cosas, pero desde luego fue imprescindible el trabajo previo. En el caso de Windows era necesario tener los últimos Service Packs aplicados, tanto a nivel se sistema operativo como del paquete Office. Dicho así parece trivial, pero en grandes clientes para actualizar un parque de miles de máquinas había que trabajar duro en automatizar los procesos, que podían requerir múltiples reinicios y simular pulsaciones de ratón y teclado concretas en momentos precisos.
También, muchas aplicaciones antiguas hechas en DBase, Clipper, etc. directamente tuvieron que rehacese en sistemas más modernos.
Para que te hagas una idea, a mí me tocó gestionar ese tema en una cervecera con fábricas por toda España, y para asegurarnos de que todo iba a salir bien nos montamos una réplica del CPD en un almacén con unos diez o doce servidores que tenían todos los servicios más representativos, y jugando con las horas de las máquinas probamos todo tipo de transiciones de década: con los servidores encendidos, con los servidores apagados, y distintas combinaciones. Cada vez que se probaba había que restaurar los equipos tirando de cintas de backup, así que una de esas pruebas duraba varios días de dedicación exclusiva.
#18 ¿Quedamos el 3 para unas birras?
#61 Vale, si viajamos al pasado o ponemos mucho empeño, pues también interno si quieres, pero creo que estaremos de acuerdo en que no es muy eficiente ni está pensado para eso. El mensaje al que respondía decía "cualquier sistema que se precie lo hace así internamente". Se deduciría entonces que Unix no es un sistema que se precie...
#67 Algo sí tuvo lugar, porque no todo el mundo fue capaz de corregir todo lo que había que corregir. Buscando un poco se encuentran algunos ejemplos graciosos:
https://www.mentalfloss.com/article/610706/problems-caused-by-y2k
#21 No lo veras si no lo pides asi.
Muchos sistemas lo almacenan asi.. luego lo muestran segun configures tu "LOCALE"
el almacena decimales.. luego si los separe con comas o puntos es cosa tuya.. el almacena numeros.. luego si los miles se agrupan con comas o puntos o con nada es tambien cosa tuya.
#75 hola
Si us sistema operativo te lista los ficheros ddmmaaaa.pdf ordenados por aaaa, mm, dd será porque tú le has diseñado una lógica para que lo haga así, no por ningún locale porque el sistema no sabe que el nombre de ese fichero es ddmmaaaa, por muy locale que le configures.
#72 en que cae?
#69 Te hablo de memoria, yo guardaba los años con dos dígitos y creo que, internamente, también eran guardados así. Apareció un parche (Y2000) que resolvía el problema. Pero hace tantos años y he escrito tanto código después que, la verdad, ya no me acuerdo.
#77 a y cuarto
#73 si viajamos al pasado o ponemos mucho empeño,
¿A ti mysql por ejemplo te parece el pasado?
no es muy eficiente ni está pensado para eso
Al contrario... permite grabar cualqueir fecha sin límites desde el 0000-00-00 hasta el 9999-99-99. Permite hacer comparaciones directas por mayor, menor o igual y no tiene problemas de año 2000, ni año 2038.
#80 Una cosa es cómo haces la consulta, y otra cómo se guarda por dentro, internamente. Para lo segundo, encontré esto:
https://dev.mysql.com/doc/internals/en/date-and-time-data-type-representation.html
Como puedes ver, los valores de tipo datetime no se guardan según su representación como caracteres ASCII (porque gastarías 4 bytes solamente para el año) sino que se empaquetan de forma eficiente dependiendo del número de bits que necesite cada cosa.
#63 exacto, no me faltará el trabajo