Identifica qué reloj estás mostrando
Al presentar conversaciones históricas de Reddit en tu aplicación, el principal reto es aclarar qué marca temporal define su antigüedad. La creación en origen, el momento en que tu app obtuvo el registro y su incorporación al archivo responden a preguntas distintas. No los etiquetes todos como Actualizado. Una solicitud de hoy puede recuperar una conversación antigua sin volver actual su contenido.
En la función hipotética de senderismo, quien compara consejos sobre offline maps necesita saber que la referencia es histórica. Si existe un valor created_utc válido, identifica la fecha mostrada como creación de la publicación o comentario de origen. La API devuelve registros planos de la fuente; no supongas que todos incluyen ese campo o que su valor sirve para mostrarse.
Diseña un estado real para las fechas ausentes
Considera dos etiquetas propuestas, no ejemplos recuperados: Fecha original: disponible en el registro y Fecha original: no disponible. La segunda tarjeta debe seguir siendo legible sin sustituir silenciosamente el dato por hoy. La falta de fecha es falta de evidencia, no prueba de que la conversación sea nueva.
Valida el tipo y el rango del campo antes de formatearlo. En una etiqueta relativa como hace años, aclara su base y proporciona una fecha absoluta comprensible cuando sea posible. Ten en cuenta la zona horaria de presentación. Si el reloj del cliente está mal o el valor no puede interpretarse con confianza, usa un estado conservador de fecha ausente en lugar de una antigüedad precisa pero poco fiable.
Separa el historial de recuperación
Tu app puede registrar cuándo obtuvo o guardó un elemento para explicar el estado de su lista local. Etiqueta ese valor como Recuperado por esta app o Guardado localmente. Describe una acción de la app, no la creación, última edición, última respuesta, incorporación al archivo ni exactitud presente del registro. Tampoco mide la latencia por sí solo.
No fabriques una fecha de incorporación al archivo a partir del momento de la solicitud. La interfaz actual no promete esa marca temporal para cada registro. Tampoco debes deducir un período completo de cobertura a partir del elemento más antiguo o reciente de una respuesta pequeña. La ausencia de resultados puede tener varias explicaciones y no demuestra que una conversación nunca existiera.
Filtra por fecha sin prometer una cronología
Filtrar por fecha reduce el alcance de la búsqueda, pero no proporciona orden cronológico. from y to aceptan fechas YYYY-MM-DD en UTC e incluyen todo el día to. Una solicitud hipotética con from=2025-01-01 y to=2025-12-31 pide ese intervalo de creación en origen; no solicita primero el resultado más reciente.
El servicio devuelve el orden _doc del archivo. Si tu app ordena localmente los registros obtenidos por un campo de creación válido, descríbelo como una ordenación de los registros cargados. Eso no demuestra que la primera tarjeta sea la coincidencia más reciente de todo el archivo. Los registros sin fecha utilizable necesitan una posición separada y explicada, no una marca temporal inventada.
Relaciona la fecha con la decisión del lector
Una conversación antigua puede ayudar a decidir qué investigar sobre mapas sin conexión: preparación de descargas, uso de batería o límites del dispositivo. No demuestra que una ruta esté abierta, que un producto funcione igual hoy ni que una solución pasada siga siendo adecuada. Separa la lectura de la navegación y de la información de seguridad actual.
Una etiqueta histórica discreta resulta más útil que una insignia de actualidad sin fundamento. Evita Actividad reciente, Totalmente sincronizado o Consejos en directo sin pruebas independientes para esa afirmación; la respuesta del archivo no las aporta. Conserva los enlaces de origen cuando existan y gestiona páginas que hayan cambiado o desaparecido. Regresa a /es/#field-notes para diseñar tarjetas y listas locales de lectura.
