Nommer l’horloge présentée
Lorsqu’une application présente des discussions historiques de Reddit, il faut préciser quel horodatage définit leur âge. La création du contenu, sa récupération par votre application et son entrée dans l’archive répondent à des questions distinctes. Ne les appelez pas tous Mis à jour. Une requête d’aujourd’hui peut récupérer une ancienne discussion sans actualiser son contenu.
Pour la fonction de randonnée hypothétique, le lecteur comparant des conseils sur offline maps doit savoir qu’une référence est historique. Si un created_utc valide est présent, décrivez la date comme celle de création de la publication ou du commentaire d’origine. L’API renvoie des données à plat ; ne supposez pas que chaque enregistrement possède ce champ ou une valeur affichable.
Prévoir réellement le cas des dates absentes
Considérez deux libellés proposés, pas des exemples récupérés : Date d’origine disponible dans l’enregistrement et Date d’origine indisponible. La seconde fiche doit rester lisible sans remplacer subrepticement la date par aujourd’hui. Une date manquante est une preuve absente, pas la preuve que le contenu est nouveau.
Validez le type et la plage du champ avant sa mise en forme. Pour une indication relative telle que il y a plusieurs années, précisez sa base et donnez une date absolue compréhensible si possible. Tenez compte du fuseau d’affichage. Si l’horloge du client est incorrecte ou la valeur douteuse, préférez un état prudent de date absente à un âge précis mais peu fiable.
Garder l’historique de récupération séparé
Votre application peut enregistrer quand elle a récupéré ou sauvegardé un élément pour expliquer sa liste locale. Utilisez un libellé comme Récupéré par cette application ou Enregistré localement. Il décrit l’action de l’application, pas la création, dernière modification, dernière réponse, entrée dans l’archive ou validité actuelle du contenu. Il ne mesure pas non plus la latence à lui seul.
N’inventez pas une date d’archivage à partir de l’heure de la requête. L’interface actuelle ne promet pas cet horodatage pour chaque enregistrement. Ne déduisez pas davantage une période complète de couverture à partir du plus ancien ou récent élément d’une petite réponse. Un résultat absent peut avoir plusieurs causes et ne prouve pas que la discussion n’a jamais existé.
Filtrer par date sans annoncer une chronologie
Le filtre de date réduit la recherche mais ne fournit pas de tri chronologique. from et to acceptent des dates YYYY-MM-DD en UTC, en incluant toute la journée to. Une demande hypothétique from=2025-01-01 et to=2025-12-31 vise cet intervalle de création, sans demander le résultat le plus récent en premier.
Le service renvoie l’ordre _doc. Si votre application trie localement les données reçues selon une date de création valide, décrivez ce tri comme celui des seuls éléments chargés. Il n’établit pas que la première fiche soit la correspondance la plus récente de toute l’archive. Les dates inutilisables nécessitent un placement séparé et expliqué, pas un horodatage fabriqué.
Relier la date à la décision du lecteur
Une vieille discussion peut aider à choisir les questions à examiner sur les cartes hors ligne : téléchargement préalable, batterie ou limites de l’appareil. Elle n’établit pas qu’un itinéraire est ouvert, qu’un produit fonctionne encore de la même manière ou qu’une ancienne solution convient toujours. Séparez la lecture de la navigation et des consignes actuelles de sécurité.
Un libellé historique sobre vaut mieux qu’un badge de fraîcheur sans preuve. Évitez Actif récemment, Entièrement synchronisé ou Conseils en direct sans preuve distincte pour cette affirmation ; cette réponse n’en apporte pas. Gardez les liens disponibles et gérez une source modifiée ou disparue. Retrouvez sur /fr/#field-notes les fiches et la liste locale.
