Domanda Buone pratiche per l'ora legale e il fuso orario [chiusa]


Spero di fare questa domanda e le risposte ad essa la guida definitiva per affrontare l'ora legale, in particolare per affrontare i cambiamenti effettivi.

Se hai qualcosa da aggiungere, per favore fallo

Molti sistemi dipendono dal tenere un tempo preciso, il problema è con i cambiamenti di tempo dovuti all'ora legale - spostando l'orologio avanti o indietro.

Ad esempio, uno ha regole di business in un sistema di ordini che dipende dal momento dell'ordine - se l'orologio cambia, le regole potrebbero non essere chiare. Come dovrebbe essere mantenuto il tempo dell'ordine? Ci sono naturalmente un numero infinito di scenari: questo è semplicemente un esempio.

  • Come hai affrontato il problema dell'ora legale?
  • Quali presupposti fanno parte della tua soluzione? (cercando il contesto qui)

Importante, se non di più:

  • Cosa hai provato che non ha funzionato?
  • Perché non ha funzionato?

Sarei interessato alla programmazione, al sistema operativo, alla persistenza dei dati e ad altri aspetti pertinenti del problema.

Le risposte generali sono grandiose, ma mi piacerebbe anche vedere i dettagli, soprattutto se sono disponibili solo su una piattaforma.


1885


origine


risposte:



Riepilogo delle risposte e altri dati: (per favore aggiungi il tuo)

Fare:

  • Ogni volta che ti riferisci a un momento preciso, continua il tempo secondo uno standard unificato che non è influenzato dall'ora legale. (GMT e UTC sono equivalenti a questo proposito, ma è preferibile utilizzare il termine UTC. Si noti che UTC è anche noto come zulù o Z tempo.)
  • Se invece si sceglie di mantenere un orario utilizzando un valore orario locale, includere l'offset dell'ora locale per questo particolare orario da UTC (questo offset può cambiare durante l'anno), in modo che il timestamp possa essere successivamente interpretato in modo univoco.
  • In alcuni casi, potrebbe essere necessario archiviare entrambi l'ora UTC e l'ora locale equivalente. Spesso questo viene fatto con due campi separati, ma alcune piattaforme supportano a datetimeoffset tipo che può archiviare entrambi in un singolo campo.
  • Quando si memorizzano le marche temporali come valore numerico, utilizzare Tempo Unix - che è il numero di interi secondi da allora 1970-01-01T00:00:00Z (esclusi i secondi bisestili). Se hai bisogno di maggiore precisione, usa invece i millisecondi. Questo valore dovrebbe sempre essere basato su UTC, senza alcuna regolazione del fuso orario.
  • Se in un secondo momento è necessario modificare il timestamp, includere l'ID del fuso orario originale in modo da poter determinare se l'offset potrebbe essere cambiato rispetto al valore originale registrato.
  • Quando si pianificano eventi futuri, in genere si preferisce l'ora locale anziché l'ora UTC, poiché è normale che l'offset cambi. Vedi la risposta, e post sul blog.
  • Quando si memorizzano intere date, come compleanni e anniversari, non convertire in UTC o in qualsiasi altro fuso orario.
    • Quando possibile, memorizzare in un tipo di dati solo data che non include un'ora del giorno.
    • Se tale tipo non è disponibile, accertarsi di ignorare sempre l'ora del giorno nell'interpretazione del valore. Se non si può essere certi che l'ora del giorno verrà ignorata, selezionare 12:00 Noon, anziché 00:00 Mezzanotte come orario rappresentativo più sicuro in quel giorno.
  • Ricorda che gli offset del fuso orario non sono sempre un numero intero di ore (ad esempio, l'ora standard indiana è UTC + 05: 30 e Nepal utilizza UTC + 05: 45).
  • Se si utilizza Java, utilizzare java.time per Java 8 o uso Joda Time per Java 7 o versioni precedenti.
  • Se si utilizza .NETTO, considera l'utilizzo Noda Time.
  • Se si utilizza .NET senza Noda Time, consideralo DateTimeOffset è spesso una scelta migliore di DateTime.
  • Se usi Perl, usa Appuntamento.
  • Se usi Python, usa pytz o dateutil.
  • Se si utilizza JavaScript, utilizzare moment.js con il momento-fuso orario estensione.
  • Se si utilizza PHP> 5.2, utilizzare le conversioni dei fusi orari nativi fornite da DateTime, e DateTimeZone classi. Fai attenzione quando usi DateTimeZone::listAbbreviations() - vedere la risposta. Per mantenere PHP aggiornato con i dati Olson, installare periodicamente il timezonedb Pacchetto PECL; vedere la risposta.
  • Se usi C ++, assicurati di usare una libreria che usi correttamente gli strumenti Database di fuso orario IANA. Questi includono cctz, ICU, e La biblioteca "tz" di Howard Hinnant.
    • Non usare Incremento per le conversioni del fuso orario. Mentre la sua API afferma di supportare gli identificatori IANA standard (noti anche come "zoneinfo") li mappa in modo rozzo a dati in stile POSIX, senza considerare la ricca storia di modifiche che ogni zona può avere avuto. (Inoltre, il file è caduto fuori manutenzione).
  • La maggior parte delle regole aziendali utilizza il tempo civile anziché UTC o GMT. Pertanto, pianificare la conversione dei timestamp UTC in un fuso orario locale prima di applicare la logica dell'applicazione.
  • Ricorda che i fusi orari e gli offset non sono fissi e possono cambiare. Ad esempio, storicamente, Stati Uniti e Regno Unito hanno utilizzato le stesse date per "far progredire" e "ripiegare". Tuttavia, nel 2007 gli Stati Uniti hanno cambiato le date in cui gli orologi vengono cambiati. Questo significa che per 48 settimane l'anno la differenza tra ora di Londra e ora di New York è di 5 ore e per 4 settimane (3 in primavera, 1 in autunno) è di 4 ore. Essere consapevoli di articoli come questo in tutti i calcoli che coinvolgono più zone.
  • Considerare il tipo di tempo (tempo effettivo dell'evento, tempo di trasmissione, tempo relativo, tempo storico, tempo ricorrente) quali elementi (data / ora, fuso orario e nome del fuso orario) è necessario memorizzare per il recupero corretto - vedere "Tipi di tempo" in questa risposta.
  • Mantieni sincronizzati i tuoi file OS, database e applicazioni tzdata, tra loro e il resto del mondo.
  • Sui server, imposta gli orologi hardware e gli orologi del sistema operativo su UTC anziché su un fuso orario locale.
  • Indipendentemente dal precedente punto elenco, codice lato server, inclusi i siti Web, dovrebbe mai si aspetta che il fuso orario locale del server sia qualcosa in particolare. vedere la risposta.
  • Preferisci lavorare con i fusi orari caso per caso nel codice della tua applicazione, piuttosto che globalmente attraverso le impostazioni del file di configurazione o i valori predefiniti.
  • Uso NTP servizi su tutti i server.
  • Se si utilizza FAT32, ricorda che i timestamp sono memorizzati in ora locale, non in UTC.
  • Quando si tratta di eventi ricorrenti (ad esempio show televisivi settimanali), ricorda che l'ora cambia con l'ora legale e sarà diversa tra i fusi orari.
  • Esegui sempre query sui valori di data-ora come escluso limite inferiore, esclusivo limite superiore (>=, <).

Non:

  • Non confondere un "fuso orario", come ad esempio America/New_York con un "offset fuso orario", come -05:00. Sono due cose differenti. Vedere il wiki del tag timezone.
  • Non usare JavaScript Date oggetto di eseguire calcoli di data e ora nei browser Web precedenti, come ha ECMAScript 5.1 e versioni precedenti un difetto di progettazione che potrebbe utilizzare l'ora legale in modo errato. (È stato corretto in ECMAScript 6/2015).
  • Non fidarti mai dell'orologio del cliente. Potrebbe benissimo essere errato.
  • Non dire alle persone di "usare sempre l'UTC ovunque". Questo consiglio diffuso è miope di diversi scenari validi descritti in precedenza in questo documento. Invece, utilizzare il riferimento temporale appropriato per i dati con cui si sta lavorando. (timestamping può utilizzare UTC, ma la pianificazione temporale futura e i valori di sola data non dovrebbero.)

test:

  • Durante i test, assicurati di testare i paesi in occidente, orientale, settentrionale e Meridionale emisferi (in effetti in ogni quarto del globo, quindi in 4 regioni), con DST in corso e non (dà 8), e un paese che non usa l'ora legale (un altro 4 per coprire tutte le regioni, facendo 12 in totale).
  • Prova la transizione dell'ora legale, ad esempio quando sei attualmente in estate, seleziona un valore temporale dall'inverno.
  • Verifica i casi limite, ad esempio un fuso orario che è UTC + 12, con ora legale, che indica l'ora locale UTC + 13 in estate e anche luoghi che sono UTC + 13 in inverno
  • Prova tutte le librerie e le applicazioni di terze parti e assicurati che gestiscano correttamente i dati del fuso orario.
  • Prova i fusi orari di mezz'ora, almeno.

Riferimento:

Altro:

  • Fai pressione sul tuo rappresentante per porre fine all'abominio che è l'ora legale. Possiamo sempre sperare ...
  • Lobby per Earth Standard Time

802



Non sono sicuro di quello che posso aggiungere alle risposte sopra, ma qui ci sono alcuni punti da parte mia:

Tipi di volte

Ci sono quattro diverse volte che dovresti considerare:

  1. Orario dell'evento: ad esempio, il momento in cui si verifica un evento sportivo internazionale, o un'incoronazione / morte / ecc. Questo dipende dal fuso orario dell'evento e non dallo spettatore.
  2. Ora della televisione: ad esempio, un particolare programma televisivo viene trasmesso alle 21:00 ora locale in tutto il mondo. Importante quando si pensa di pubblicare i risultati (di American Idol) sul tuo sito web
  3. Tempo relativo: ad esempio: questa domanda ha una taglia aperta che si chiude in 21 ore. Questo è facile da visualizzare
  4. Tempo ricorrente: ad esempio: un programma TV è attivo ogni lunedì alle 21:00, anche quando l'ora legale cambia.

C'è anche il tempo storico / alternativo. Questi sono fastidiosi perché potrebbero non essere ritrasferiti al tempo standard. Es: date giuliane, date secondo un calendario lunare su Saturno, il calendario Klingon.

Memorizzare i timestamp di inizio / fine in UTC funziona bene. Per 1, è necessario un nome fuso orario evento + offset memorizzato insieme all'evento. Per 2, è necessario un identificatore dell'ora locale memorizzato con ogni regione e un nome fuso orario locale + offset memorizzato per ogni visualizzatore (è possibile ricavarlo dall'IP se si è in crisi). Per 3, memorizzare in secondi UTC e senza bisogno di fusi orari. 4 è un caso speciale di 1 o 2 a seconda che si tratti di un evento globale o locale, ma è anche necessario memorizzare un creato a timestamp in modo da poter stabilire se una definizione del fuso orario è cambiata prima o dopo la creazione di questo evento. Questo è necessario se è necessario mostrare i dati storici.

Memorizzare i tempi

  • Memorizza sempre il tempo in UTC
  • Converti in ora locale sul display (locale definito dall'utente che guarda i dati)
  • Quando si memorizza un fuso orario, è necessario il nome, il timestamp e l'offset. Questo è necessario perché i governi a volte cambiano il significato dei loro fusi orari (ad esempio: il governo USA modifica le date dell'ora legale) e la tua applicazione deve gestire le cose con garbo ... es .: Il timestamp esatto quando gli episodi di LOST mostrano sia prima che dopo le regole dell'ora legale cambiato.

Offset e nomi

Un esempio di quanto sopra sarebbe:

Il gioco delle finali di coppa del mondo di calcio   successo in Sud Africa (UTC + 2 - SAST)   l'11 luglio 2010 alle 19:00 UTC.

Con queste informazioni, possiamo determinare storicamente l'ora esatta in cui si sono svolte le finali del WCS 2010 anche se la definizione del fuso orario del Sud Africa cambia, e essere in grado di mostrarlo agli spettatori nel loro fuso orario locale nel momento in cui interrogano il database.

Tempo di sistema

È inoltre necessario mantenere sincronizzati i file tzdata del sistema operativo, del database e dell'applicazione, sia l'uno con l'altro, sia con il resto del mondo e testare ampiamente quando si esegue l'aggiornamento. Non è raro che un'applicazione di terze parti da cui dipendi non abbia gestito correttamente una modifica di TZ.

Assicurati che gli orologi hardware siano impostati su UTC e, se stai utilizzando server in tutto il mondo, assicurati che i loro sistemi operativi siano configurati per utilizzare anche UTC. Ciò risulta evidente quando è necessario copiare i file di registro Apache ruotati ogni ora dai server in più fusi orari. Ordinandoli per nome file funziona solo se tutti i file hanno lo stesso fuso orario. Significa anche che non devi fare i calcoli matematici in testa quando usi ssh da una casella a un'altra e devi confrontare i timestamp.

Inoltre, esegui ntpd su tutte le caselle.

clienti

Non fidarti mai della validità del timestamp che ricevi da un computer client. Ad esempio, Date: intestazioni HTTP o javascript Date.getTime() chiamata. Questi vanno bene quando vengono usati come identificativi opachi, o quando si fa matematica di date durante una singola sessione sullo stesso client, ma non si tenta di fare un riferimento incrociato a questi valori con qualcosa che si ha sul server. I tuoi client non eseguono NTP e potrebbero non avere necessariamente una batteria funzionante per il loro orologio BIOS.

banalità

Infine, i governi a volte faranno cose molto strane:

Era il momento standard nei Paesi Bassi   esattamente 19 minuti e 32,13 secondi   prima dell'UTC per legge dal 1909-05-01   fino al 1937-06-30. Questo fuso orario   non può essere rappresentato usando esattamente   il formato HH: MM.

Ok, penso di aver finito.


288



Questo è un problema importante e sorprendentemente difficile. La verità è che non esiste uno standard completamente soddisfacente per il tempo persistente. Ad esempio, lo standard SQL e il formato ISO (ISO 8601) non sono chiaramente sufficienti.

Dal punto di vista concettuale, di solito si tratta di due tipi di dati di data / ora, ed è conveniente distinguerli (gli standard di cui sopra non lo sono): "tempo fisico" e "tempo civile".

Un istante temporale "fisico" è un punto nella continua linea temporale universale di cui la fisica si occupa (ignorando la relatività, ovviamente). Questo concetto può essere adeguatamente codificato-persistente in UTC, ad esempio (se si può ignorare il secondo intercalare).

Un tempo "civile" è una specifica datetime che segue le norme civili: un punto temporale qui è completamente specificato da un insieme di campi datetime (Y, M, D, H, MM, S, FS) più una TZ (specifica del fuso orario) (anche un "calendario", in realtà; ma assumiamo che limitiamo la discussione al calendario gregoriano). Un fuso orario e un calendario consentono (in linea di principio) di mappare da una rappresentazione all'altra. Ma gli istanti temporali civili e fisici sono tipi di magnitudo fondamentalmente diversi, e dovrebbero essere mantenuti separati concettualmente e trattati in modo diverso (un'analogia: matrici di byte e stringhe di caratteri).

Il problema è confuso perché parliamo di questi tipi di eventi in modo intercambiabile e perché i tempi civili sono soggetti a cambiamenti politici. Il problema (e la necessità di distinguere questi concetti) diventa più evidente per gli eventi futuri. Esempio (tratto dalla mia discussione Qui.

John registra nel suo calendario un promemoria per alcuni eventi a data / ora 2019-Jul-27, 10:30:00, TZ =Chile/Santiago, (che ha compensato GMT-4, quindi corrisponde a UTC 2019-Jul-27 14:30:00). Ma un giorno in futuro, il paese decide di cambiare l'offset TZ in GMT-5.

Ora, quando arriverà il giorno ... dovrebbe iniziare quel promemoria

UN) 2019-Jul-27 10:30:00 Chile/Santiago  = UTC time 2019-Jul-27 15:30:00 ?

o

B) 2019-Jul-27 9:30:00 Chile/Santiago  = UTC time 2019-Jul-27 14:30:00 ?

Non c'è una risposta corretta, a meno che non si sappia ciò che John intendeva concettualmente quando ha detto al calendario "Per favore chiamami a 2019-Jul-27, 10:30:00 TZ=Chile/Santiago".

Intendeva un "appuntamento civile" ("quando gli orologi della mia città raccontano 10:30 ")? In tal caso, A) è la risposta corretta.

O intendeva un "istante fisico del tempo", un punto nel continuo linea del tempo del nostro universo, diciamo "quando la prossima eclissi solare" succede ". In tal caso, la risposta B è corretta.

Alcune API Data / Ora ottengono questa distinzione nel modo giusto: tra queste, Jodatime, che è la base della prossima (terza!) Java DateTime API (JSR 310).


81



Crea una chiara separazione architettonica delle preoccupazioni: per sapere esattamente quale livello interagisce con gli utenti e deve modificare la data-ora per / dalla rappresentazione canonica (UTC). La data non UTC è la presentazione (segue il fuso orario locale dell'utente), L'ora UTC è il modello (rimane unico per back-end e mid tiers).

Anche, decidere qual è il tuo pubblico attuale, cosa non devi servire e dove traccia la linea. Non toccare i calendari esotici a meno che tu non abbia effettivamente clienti importanti lì e quindi consideri i server separati per utente solo per quella regione.

Se è possibile acquisire e gestire la posizione dell'utente, utilizzare l'ubicazione per la conversione sistematica della data / ora (ad esempio cultura .NET o una tabella SQL) ma fornire un modo per l'utente finale di scegliere l'override se la data-ora è fondamentale per gli utenti.

Se ci sono obblighi di revisione storica coinvolto (come dire esattamente quando Jo in AZ ha pagato un conto 2 anni fa a settembre) quindi mantieni sia l'ora locale sia quella locale per la cronaca (le tue tabelle di conversione cambieranno nel corso del tempo).

Definisci il fuso orario referenziale in tempo per i dati che arrivano alla rinfusa - come file, servizi web, ecc. La società della Costa orientale ha un centro dati in CA - è necessario chiedere e sapere che cosa usano come standard invece di assumere l'uno o l'altro.

Non fidatevi degli offset della fascia oraria incorporati nella rappresentazione testuale della data e dell'ora non accettare di analizzare e seguirli Richiedere invece sempre che il fuso orario e / o la zona di riferimento debbano essere definiti in modo esplicito. È possibile ricevere facilmente il tempo con l'offset PST, ma il tempo è in realtà EST poiché questo è il tempo di riferimento del cliente e i record sono stati appena esportati in un server che si trova in PST.


53



Devi sapere qualcosa sull'Olson database tz, che è disponibile da ftp://elsie.nci.nih.gov/pub  http://iana.org/time-zones/. Viene aggiornato più volte all'anno per gestire i cambiamenti spesso dell'ultimo minuto in quando (e se) per passare da un periodo invernale ad uno estivo (standard e ora legale) in diversi paesi in tutto il mondo. Nel 2009, l'ultima versione è stata 2009; nel 2010 era il 2010; nel 2011 era il 2011; alla fine di maggio 2012, l'uscita era 2012c. Si noti che esiste un set di codice per gestire i dati e i dati effettivi del fuso orario stesso, in due archivi separati (tzcode20xxy.tar.gz e tzdata20xxy.tar.gz). Sia il codice che i dati sono di dominio pubblico.

Questa è la fonte dei nomi dei fusi orari come America / Los_Angeles (e sinonimi come Stati Uniti / Pacifico).

Se è necessario tenere traccia delle diverse zone, è necessario il database Olson. Come altri hanno consigliato, si desidera anche archiviare i dati in un formato fisso: l'UTC è normalmente quello scelto, insieme a un record del fuso orario in cui sono stati generati i dati. Si consiglia di distinguere tra l'offset da UTC al momento e il nome del fuso orario; questo può fare la differenza in seguito. Inoltre, sapendo che è attualmente 2010-03-28T23: 47: 00-07: 00 (USA / Pacifico) può o non può aiutarti nell'interpretazione del valore 2010-11-15T12: 30 - che è presumibilmente specificato in PST ( Pacific Standard Time) anziché PDT (Pacific Daylight Saving Time).

Le interfacce di libreria C standard non sono terribilmente utili con questo genere di cose.


I dati di Olson si sono spostati, in parte perché A D Olson andrà in pensione presto, e in parte perché c'è stata una (ora licenziata) causa legale contro i manutentori per violazione del copyright. Il database dei fusi orari è ora gestito sotto gli auspici di IANA, l'Internet Numbers Authority assegnata, e c'è un link in prima pagina a 'Database dei fusi orari'. La mailing list della discussione è ora tz@iana.org; la lista degli annunci è tz-announce@iana.org.


38



In generale, includere l'offset dell'ora locale (incluso l'offset dell'ora legale) nei timestamp archiviati: l'UTC da solo non è sufficiente se in seguito si desidera visualizzare il timestamp nel suo fuso orario originale (e l'impostazione di ora legale).

Tieni presente che l'offset non è sempre un numero intero di ore (ad esempio, l'ora standard indiana è UTC + 05: 30).

Ad esempio, i formati adatti sono una tupla (tempo unix, offset in minuti) o ISO 8601.


24



Attraversare il confine tra "tempo del computer" e "tempo delle persone" è un incubo. Il principale è che non esiste alcun tipo di standard per le regole che regolano i fusi orari e l'ora legale. I Paesi sono liberi di cambiare il loro fuso orario e le regole del DST in qualsiasi momento, e lo fanno.

Alcuni paesi, ad es. Israele, Brasile, decide ogni anno quando avere l'ora legale, quindi è impossibile sapere in anticipo quando (se) sarà in vigore l'ora legale. Altri hanno fissato regole (ish) su quando è in vigore l'ora legale. Altri paesi non usano l'ora legale come tutti.

I fusi orari non devono essere le differenze orarie complete da GMT. Il Nepal è +5,45. Esistono anche fusi orari che sono +13. Ciò significa che:

SUN 23:00 in Howland Island (-12)
MON 11:00 GMT 
TUE 00:00 in Tonga (+13)

sono tutti allo stesso tempo, ancora 3 giorni diversi!

Inoltre non esiste uno standard chiaro sulle abbreviazioni per i fusi orari e su come cambiano durante l'ora legale, quindi ci si ritrova in situazioni come questa:

AST Arab Standard Time     UTC+03
AST Arabian Standard Time  UTC+04
AST Arabic Standard Time   UTC+03

Il miglior consiglio è di stare lontano dai tempi locali il più possibile e attenersi a UTC dove puoi. Converti solo in orari locali all'ultimo momento possibile.

Durante i test assicurati di testare i paesi negli emisferi occidentale e orientale, con l'ora legale in corso e non con un paese che non utilizza l'ora legale (6 in totale).


22



Per PHP:

La classe DateTimeZone in PHP> 5.2 è già basata sul database Olson che altri menzionano, quindi se stai facendo le conversioni del fuso orario in PHP e non nel DB, sei esente dal lavorare con i file Olson (difficili da capire).

Tuttavia, PHP non viene aggiornato con la frequenza di Olson DB, quindi utilizzare solo le conversioni del fuso orario di PHP potrebbe lasciarti con informazioni DST obsolete e influenzare la correttezza dei tuoi dati. Anche se questo non dovrebbe accadere frequentemente, può accadere, e volere capita se hai una grande base di utenti in tutto il mondo.

Per far fronte al problema precedente, utilizzare il pacchetto pecl timezonedb, questa è la funzione per aggiornare i dati del fuso orario di PHP. Installa questo pacchetto con la frequenza con cui viene aggiornato. (Non sono sicuro che gli aggiornamenti di questi pacchetti seguano esattamente gli aggiornamenti di Olson, ma sembra essere aggiornato in una frequenza che è per lo meno molto vicina agli aggiornamenti di Olson.)


18



Se il tuo progetto può adattarlo, evitare la conversione dell'ora locale tutti insieme! 

So che alcuni potrebbero sembrare folle ma pensare a UX: gli utenti elaborano le date relative (oggi, ieri, lunedì prossimo) più velocemente rispetto alle date assolute (2010.09.17, venerdì 17 settembre). E se ci pensate di più, la precisione dei fusi orari (e DST) è più importante quanto più vicina è la data now(), quindi se puoi esprimere date / datetimes in un formato relativo per +/- 1 o 2 settimane, il resto delle date può essere UTC e non importa troppo al 95% degli utenti.

In questo modo è possibile memorizzare tutte le date in UTC e fare i relativi confronti in UTC e mostrare semplicemente le date UTC dell'utente al di fuori della soglia relativa della data.

Questo può valere anche per l'input dell'utente (ma generalmente in modo più limitato). La selezione da un menu a discesa che ha solo {ieri, oggi, domani, lunedì successivo, giovedì prossimo} è molto più semplice e facile per l'utente rispetto a un selettore di date. I raccoglitori di date sono alcuni dei componenti più inducenti il ​​dolore del riempimento dei moduli. Ovviamente questo non funzionerà per tutti i casi, ma puoi vedere che ci vuole solo un piccolo disegno intelligente per renderlo molto potente.


15