Dare un nome all’orologio mostrato
Quando mostri discussioni storiche di Reddit nell’app, la difficoltà più importante è chiarire quale timestamp ne definisca l’età. La creazione della fonte, il recupero di un record da parte dell’app e la sua acquisizione nell’archivio rispondono a domande diverse. Non etichettarli tutti Aggiornato. Una richiesta di oggi può recuperare una vecchia discussione senza renderne attuale il contenuto.
Nella funzione escursionistica ipotetica, chi confronta consigli sulle mappe offline deve sapere che un riferimento è storico. Se esiste un valore created_utc valido, indica la data come creazione del post o commento di origine. L’API inoltra record sorgente piatti: non presumere che ogni record includa quel campo o che il suo valore sia visualizzabile correttamente.
Prevedere uno stato reale per le date mancanti
Considera due etichette proposte per le schede, non esempi recuperati: Data originale: disponibile nel record, e Data originale: non disponibile. La seconda scheda deve restare leggibile senza sostituire tacitamente la data odierna. Un timestamp mancante è assenza di prova, non prova che la discussione sia nuova.
Valida tipo e intervallo del campo prima di formattarlo. Per un’indicazione relativa come anni fa, chiarisci la base e fornisci, se possibile, una data assoluta comprensibile. Considera il fuso orario di visualizzazione dell’app. Se l’orologio del client è errato o il valore non è interpretabile con sicurezza, usa uno stato prudente di data mancante invece di un’età precisa ma inaffidabile.
Separare la cronologia dei recuperi
L’app può registrare quando ha recuperato o salvato un elemento per spiegare lo stato della lista locale. Etichetta quel valore Recuperato da questa app o Salvato localmente. Descrive l’azione dell’app, non creazione, ultima modifica, ultima risposta, acquisizione nell’archivio o accuratezza attuale del record. Non è neppure, da solo, una misura della latenza.
Non ricavare una data di acquisizione nell’archivio dall’ora della richiesta. L’interfaccia corrente non promette quel timestamp per ciascun record. Né puoi dedurre un periodo completo di copertura dal più vecchio o recente elemento di una piccola risposta. Un risultato assente può avere diverse spiegazioni e non prova che la discussione non sia mai esistita.
Filtrare le date senza promettere una sequenza cronologica
Il filtro per data restringe la ricerca ma non offre ordinamento cronologico. from e to accettano date YYYY-MM-DD in UTC, con la giornata to inclusa. Una richiesta ipotetica con from=2025-01-01 e to=2025-12-31 chiede quell’intervallo di date sorgente; non chiede il risultato più recente per primo.
Il servizio restituisce l’ordine _doc dell’archivio. Se ordini localmente i record recuperati tramite un campo di creazione valido, descrivi il risultato come ordinamento di quei record caricati. Non dimostra che la prima scheda sia la corrispondenza più recente dell’intero archivio. I record privi di data utilizzabile richiedono una collocazione distinta e spiegata, non un timestamp inventato.
Ricollegare la data alla decisione del lettore
Una discussione vecchia può aiutare a scegliere quali domande sulle mappe offline approfondire: preparazione dei download, batteria o limiti del dispositivo. Non dimostra che un percorso sia aperto, un prodotto funzioni oggi allo stesso modo o una soluzione passata sia ancora adatta. Separa la funzione di lettura da navigazione e informazioni aggiornate di sicurezza.
Un’etichetta storica sobria è più utile di un bollino di freschezza non dimostrato. Evita Attivo di recente, Completamente sincronizzato o Consigli in tempo reale senza prove separate per l’affermazione concreta: questa risposta d’archivio non le fornisce. Conserva i link disponibili e gestisci una fonte cambiata o scomparsa. Torna a /it/#field-notes per schede e lista di lettura locale.
