Sovrapposizione Londra–New York nel forex: perché ricalcolarla per ogni data

Una tabella della sovrapposizione fra Londra e New York può risultare spostata di un’ora anche se gli orari di lavoro locali non cambiano. Stati Uniti e Regno Unito spostano gli orologi in date diverse. Per una parte di marzo e alla fine di ottobre, la differenza fra le città è di quattro ore anziché delle consuete cinque. Può quindi cambiare la durata della sovrapposizione, oltre al suo inizio o alla sua fine in UTC.

Occorre definire le due fasce in ora locale e calcolarne l’intersezione per la data analizzata. Nell’esempio 08:00–17:00 in ciascuna città, la sovrapposizione dura quattro ore quando entrambe sono all’ora solare o entrambe all’ora legale; dura cinque ore quando New York è all’ora legale e Londra all’ora solare. Si tratta di intervalli calcolati, non della prova che vi siano cinque ore favorevoli per fare trading.

Definire le due fasce prima di cercare la sovrapposizione

Il mercato valutario a pronti è un mercato over-the-counter, distribuito fra intermediari e sedi di esecuzione. L’espressione sessione di Londra non stabilisce un’unica apertura ufficiale, una chiusura obbligatoria o un accesso identico per tutti i conti. Il fornitore può prevedere orari specifici per prodotto, pause di manutenzione e disposizioni particolari nei giorni festivi.

Per rendere il calcolo riproducibile, ipotizziamo una fascia lavorativa dalle 08:00 alle 17:00 nell’ora di Londra e una dalle 08:00 alle 17:00 nell’ora di New York. Entrambe si riferiscono alla stessa data di calendario locale e comprendono l’inizio, ma non l’istante finale. Sono parametri scelti per l’analisi, non gli orari ufficiali di un intermediario o di una sede di negoziazione.

Ogni orario deve conservare la data e la città: le 08:00 di Londra e le 08:00 di New York sono istanti diversi. EST significa UTC−5 e non va usato per indicare l’ora di New York durante tutto l’anno: EDT equivale a UTC−4. Londra usa GMT, equivalente a UTC in queste conversioni, oppure BST, UTC+1. L’ora di Pechino è UTC+8 in tutti gli esempi.

Controllare le date effettive dei cambi d’ora

Nel 2026 New York segue l’ora legale statunitense dall’8 marzo al 1º novembre, con passaggi alle 02:00 locali. Nel Regno Unito gli orologi avanzano il 29 marzo e tornano indietro il 25 ottobre. L’attuale regola americana usa la seconda domenica di marzo e la prima di novembre; quella britannica, l’ultima domenica di marzo e di ottobre.

Nei giorni lavorativi dal 9 al 27 marzo 2026 si hanno quindi Londra in GMT e New York in EDT. La stessa combinazione ricorre dal 26 al 30 ottobre: Londra è avanti di quattro ore. Con GMT/EST o BST/EDT, il divario è di cinque ore. Per un anno diverso occorre verificare le nuove date, senza trasformare quelle del 2026 in un calendario permanente.

Spostare l’orologio locale avanti di un’ora fa cadere lo stesso orario lavorativo un’ora prima in UTC; UTC non cambia. In primavera anticipa prima New York. In autunno torna indietro prima Londra. Questa asimmetria spiega perché possa muoversi un solo estremo della sovrapposizione, lasciando fermo l’altro.

Convertire entrambi gli intervalli in UTC e calcolarne l’intersezione

Per ogni estremo vale: ora UTC = ora locale − scarto UTC della città in quella data. Dopo aver espresso tutte le estremità in UTC, l’intersezione inizia all’apertura più tarda e finisce alla chiusura più anticipata. La sua durata è il massimo fra zero e fine meno inizio. Se si attraversa la mezzanotte, occorrono data e ora complete, non soltanto i numeri sul quadrante.

Il 9 marzo la fascia ipotizzata per Londra diventa 08:00–17:00 UTC e quella di New York 12:00–21:00 UTC. L’inizio più tardo è 12:00 e la fine più anticipata 17:00: cinque ore. Il 30 marzo Londra passa a 07:00–16:00 UTC, mentre New York resta a 12:00–21:00 UTC; la sovrapposizione scende a quattro ore.

La prima colonna riporta la data locale comune a Londra e New York nel 2026. L’ultima rende esplicito il passaggio al giorno successivo a Pechino. Per esempio, il 23 ottobre alle 16:00 UTC corrisponde al 24 ottobre alle 00:00 a Pechino, non all’inizio del 23 ottobre. L’inizio è incluso e la fine esclusa: un evento alle 16:00 UTC esatte non rientra nella sovrapposizione del 23 ottobre.

I risultati, compreso l’esempio del 2 novembre, sono calcoli di calendario basati sulle ipotesi dichiarate, non osservazioni di scambi avvenuti in quelle date. Dal 23 al 26 ottobre l’inizio UTC resta fermo e la fine slitta avanti di un’ora. Dal 26 ottobre al 2 novembre resta ferma la fine e slitta avanti l’inizio. Spostare l’intero rettangolo di un’ora non può descrivere entrambe le transizioni.

Un filtro fisso può aggiungere un’ora errata e perderne una corretta

Supponiamo che uno script mantenga ogni giorno le osservazioni dalle 12:00 incluse alle 16:00 escluse UTC, perché questa era l’impostazione estiva. Confrontiamo il filtro congelato con l’intersezione di ogni data. Le ore incluse per errore sono esterne alla sovrapposizione ipotizzata, non necessariamente agli orari di negoziazione del prodotto.

Il 2 novembre il filtro seleziona ancora quattro ore, come l’intervallo corretto, ma soltanto tre sono in comune. Include erroneamente 12:00–13:00 e omette 16:00–17:00. Una durata o un numero di righe invariato può quindi nascondere un campione di prezzi diverso. Con un’osservazione all’inizio di ogni minuto e nessun dato mancante, i due filtri contengono 240 righe ciascuno, 180 comuni e 60 esclusive di ciascun insieme. I dati mancanti richiedono un conteggio separato.

In un backtest intraday, ricostruite l’appartenenza dei timestamp prima di confrontare spread, escursioni o rendimenti. Una candela che attraversa un confine non è interamente nell’intervallo solo perché il suo orario di riferimento vi rientra. Specificate se usate eventi, candele interamente contenute o un’altra regola documentata; servono dati più granulari per una suddivisione esatta. Per la costruzione delle candele giornaliere va invece considerato l’effetto dell’orario di chiusura sulle candele giornaliere del forex. Cambiare il fuso visualizzato sul grafico non corregge automaticamente questi calcoli.

Confermare l’effetto dell’orologio senza presumere un’esecuzione migliore

La spiegazione basata sul cambio d’ora è supportata quando le due fasce locali restano invariate, gli scarti ufficiali cambiano secondo le regole e i timestamp riproducono i nuovi limiti UTC. Verificate un istante prima dell’inizio, l’inizio stesso e la fine esclusa. Se i test non coincidono, controllate il fuso memorizzato, lo scarto del server o il significato della data prima di affidarvi al nome della sessione.

L’applicabilità del risultato dipende dagli input. Un festivo, una giornata ridotta, un diverso orario dell’intermediario o una pausa del prodotto possono rendere 08:00–17:00 poco rappresentativo. Un dato economico resta legato alla base oraria del proprio calendario: non si sposta solo perché cambia l’etichetta della sovrapposizione. Disponibilità del prodotto, calendario di regolamento e intersezione delle due città sono controlli diversi.

Una conversione esatta non garantisce uno spread contenuto, quantità disponibili o l’esecuzione di un ordine. Più partecipanti potenziali non determinano la quotazione accessibile a un conto specifico, mentre un evento volatile può modificare le condizioni all’interno della fascia. Considerate la stessa coppia, fonte di prezzi, timestamp di denaro e lettera, quantità prevista ed eseguiti reali. Una candela ampia non misura la liquidità effettivamente negoziabile.

Per capire se questa fascia migliora l’esecuzione, confrontate ordini di uguale dimensione e quotazioni omogenee in un campione definito, separando annunci, festivi e osservazioni mancanti. Il calcolo orario stabilisce quali record appartengono all’intervallo; i dati misurano la qualità dell’esecuzione. Senza questi ultimi, il solo calendario non dimostra alcun vantaggio.

Creare un calendario per data che sia verificabile

Registrate prima la data di analisi, la coppia, il prodotto, ogni fascia locale ipotizzata e il relativo fuso. Nei software usate identificatori come Europe/London e America/New_York con dati aggiornati, invece di sottrarre sempre quattro o cinque ore. Conservate i timestamp originali e il fuso dei dati o del server, senza sovrascriverli con ore locali prive di indicazione del fuso.

Convertite quindi le due fasce in UTC, calcolate l’intersezione e trasformate i timestamp completi nel fuso di visualizzazione. Salvate insieme data iniziale, data finale, scarti e durata. Le sei date della prima tabella devono produrre 4, 5, 4, 4, 5 e 4 ore. Aggiungete test per l’esclusione dell’estremo finale e per la data del giorno successivo a Pechino.

Controllate poi gli orari effettivi del fornitore e le chiusure eccezionali, allineando separatamente il calendario economico e i timestamp dei dati. Se un orario è definito in UTC fisso, mantenete tale definizione: è un input diverso, non un errore da correggere di nascosto. Se in futuro una soglia locale cade in un’ora ripetuta o inesistente durante il cambio d’ora, definite come risolvere l’ambiguità. Gli esempi diurni nei giorni lavorativi evitano questo problema.

Infine, rigenerate il calendario quando cambiano le regole dei fusi o le fasce prescelte. Conservate le ipotesi accanto al risultato. Un risultato affidabile è un intervallo datato, verificabile e con un ambito esplicito, non l’affermazione che Londra e New York si sovrappongano alle stesse ore tutto l’anno.