Integrazioni e modelli dei dati
Date e fusi orari: progettare il tempo nelle integrazioni aziendali
Due sistemi possono scambiarsi lo stesso valore temporale e attribuirgli significati diversi. Un campo chiamato data potrebbe indicare il giorno di un documento, l’istante di ricezione oppure un appuntamento previsto nell’ora locale di una sede. Convertire tutto in un unico formato senza chiarire queste differenze può spostare scadenze e raggruppamenti, pur lasciando i messaggi formalmente validi. Progettare il tempo nelle integrazioni richiede quindi un contratto sul significato dei dati, oltre a una sintassi condivisa per trasmetterli.
Distinguere un istante da una data del processo
Un istante identifica un punto sulla linea temporale; una data del calendario identifica invece un giorno secondo il significato attribuito dal processo. La data di un documento, per esempio, può dover restare invariata quando viene visualizzata da una sede in un altro paese. Trasformarla arbitrariamente nella mezzanotte di un fuso e poi convertirla rischia di mostrarla nel giorno precedente. Il modello dovrebbe usare tipi e nomi distinti, così che una funzione di conversione non venga applicata a un dato che non rappresenta un orario.
Consideriamo un esempio esclusivamente illustrativo: un sistema acquisisce un ordine, ne conserva la data operativa e registra quando il messaggio viene ricevuto. Sono informazioni separate. La prima risponde a una regola del documento, la seconda descrive un evento tecnico. Nel contratto di integrazione occorre spiegare chi assegna ciascun valore, se possa essere corretto e come vengano trattati gli ingressi incompleti. Un campo generico obbliga invece ogni consumatore a indovinare il significato, aumentando la probabilità di interpretazioni incompatibili nel tempo.
Trasmettere gli istanti con un formato esplicito
RFC 3339 definisce un formato per rappresentare date e orari nei protocolli Internet, comprendendo l’indicazione dello scostamento rispetto a UTC. Per un istante di ricezione, un valore con indicazione esplicita del riferimento temporale evita di dipendere dal fuso predefinito della macchina che lo legge. Il progetto deve comunque concordare precisione, valori ammessi e comportamento di errore. Accettare silenziosamente un timestamp privo delle informazioni richieste può trasformare una configurazione locale in una regola implicita del contratto.
Anche le conversioni devono essere osservabili. Se una parte trasmette frazioni di secondo e l’altra le elimina, due eventi distinti possono apparire simultanei. L’ordinamento delle stringhe richiede cautela quando cambiano offset o rappresentazioni: per confrontare istanti è preferibile interpretarli con tipi temporali appropriati. Nel nostro esempio, il test deve inviare rappresentazioni diverse dello stesso istante e verificare che il sistema le riconosca come equivalenti, mantenendo separata la forma originale quando serve a ricostruire ciò che il mittente ha dichiarato.
Conservare la zona quando la regola dipende dall’ora locale
Lo scostamento numerico e la zona geografica rispondono a domande differenti. Un offset descrive la relazione con UTC in una certa rappresentazione; una zona come Europe/Rome permette di applicare regole di calendario locale. La banca dati IANA raccoglie queste regole e viene aggiornata quando cambiano le disposizioni delle autorità competenti. Per un’attività futura prevista alle nove presso una sede, conservare soltanto un offset fisso può quindi perdere il legame con l’orario civile che l’organizzazione intende rispettare.
RFC 9557 estende il formato dei timestamp per includere informazioni aggiuntive, tra cui una zona. La disponibilità dello standard non implica che tutti i sistemi coinvolti lo supportino. Un contratto può prevedere campi distinti per data locale, ora e identificativo della zona, purché ne specifichi la relazione e le verifiche. Nel caso illustrativo, se un operatore pianifica un’elaborazione presso una sede, l’interfaccia dovrebbe mostrare la zona considerata e impedire che il fuso del browser sostituisca senza evidenza quello dell’attività.
Definire ricorrenze e intervalli senza scorciatoie
Ripetere un’attività ogni ventiquattro ore non equivale sempre a eseguirla ogni giorno alla stessa ora locale. Per una ricorrenza aziendale bisogna decidere quale delle due regole abbia valore, come trattare giorni esclusi e che cosa fare quando un’esecuzione precedente è ancora aperta. Nei cambi dell’ora civile possono esistere orari locali ripetuti o non presenti. Il progetto deve stabilire se saltare, anticipare, posticipare o chiedere una scelta, evitando che una libreria decida implicitamente al posto del processo.
Anche un intervallo giornaliero merita una definizione precisa. Per estrarre gli eventi di una giornata locale, si possono costruire i suoi confini nel calendario della sede e convertirli negli istanti corrispondenti. Un intervallo che include l’inizio ed esclude il confine successivo evita di inventare un ultimo istante basato sulla precisione disponibile. Non si dovrebbe assumere automaticamente che ogni giornata locale abbia una durata identica. Nel nostro esempio, una prova deve verificare che ogni ordine ricada nel gruppo previsto senza apparire due volte tra estrazioni consecutive.
Separare tempo dell’evento, ricezione e sequenza
Il momento dichiarato dal mittente e quello osservato dal destinatario possono differire per ritardi di rete, accodamenti o configurazioni degli orologi. La distinzione aiuta a spiegare un evento arrivato tardi, ma non risolve da sola l’ordine delle operazioni. Un timestamp non dovrebbe diventare automaticamente una versione del record. Se due aggiornamenti riportano valori uguali o provengono da macchine con orologi non allineati, il sistema deve comunque poter applicare la regola di consistenza prevista.
Nel caso illustrativo, il contratto potrebbe affiancare all’istante dell’evento un identificativo e una revisione assegnata dal sistema proprietario dell’ordine. Il destinatario usa queste informazioni secondo una regola esplicita per riconoscere ripetizioni e aggiornamenti superati. È una scelta da concordare, non una capacità da attribuire genericamente a qualsiasi API. Per misurare la durata di un’operazione interna, inoltre, occorre valutare strumenti monotoni appropriati: il trascorrere di un’attesa non dovrebbe dipendere da una correzione dell’ora civile della macchina.
Collaudare i confini invece di provare soltanto il giorno corrente
La raccolta di prove deve comprendere passaggi tra mesi e anni, giorni di durata particolare, orari locali ambigui e configurazioni differenti tra server e client. Per l’esempio degli ordini servono almeno verifiche separate sulla data operativa, sul timestamp di ricezione e sulla pianificazione locale. I risultati attesi devono derivare dal contratto approvato. Generare molte date casuali può ampliare l’esplorazione, ma non sostituisce la scelta consapevole dei confini che hanno un significato per il processo.
È utile rendere controllabile l’orologio nelle prove, così da verificare scadenze e attese senza dipendere dal giorno in cui viene eseguito il test. Vanno provati anche valori non validi e campi mancanti, osservando quale errore venga restituito e se rimangano registrazioni parziali. Le versioni delle librerie e dei dati sui fusi devono essere riconoscibili quando incidono sull’interpretazione. Un confronto tra ambienti può altrimenti sembrare un difetto del codice quando la differenza nasce dalle regole temporali effettivamente caricate.
Rendere leggibile il contratto anche a chi gestisce le eccezioni
Un’interfaccia dovrebbe chiarire quale ora mostra, soprattutto nelle schermate usate per diagnosticare integrazioni. Visualizzare soltanto un numero locale può far apparire fuori sequenza due eventi che usano riferimenti diversi. È utile distinguere il valore originale, l’istante interpretato e la presentazione scelta per l’operatore, esponendo il dettaglio quando aiuta a prendere una decisione. Le esportazioni e i report devono seguire lo stesso significato, conservando date del documento e date degli eventi come informazioni separate.
Per il contesto applicativo, la pagina sulle API e i Web Services di Gestionale sul Web costituisce un approfondimento pertinente. I formati temporali effettivamente supportati vanno verificati nella documentazione del progetto, senza dedurli dai principi generali qui descritti. Un’integrazione robusta nasce quando ogni campo temporale ha un significato condiviso, una rappresentazione accettata e prove sui casi difficili. Questo consente di diagnosticare le differenze senza correggere manualmente i dati sulla base di semplici supposizioni.
Riferimenti tecnici
Per approfondire i temi tecnici trattati:
- RFC 3339: formato dei timestamp nei protocolli Internet
- IANA: banca dati delle zone e delle regole temporali
- RFC 9557: timestamp con informazioni aggiuntive sulla zona
Analisi metodologica originale. Gli ordini e le attività pianificate sono esempi illustrativi; non descrivono clienti, regole fiscali o formati implementati da Gestionale sul Web.
A cura della redazione tecnica SoftJob. Pubblicato il .