Cheatsheet dei fusi orari per team remoti: gli otto fusi che coprono il 90% delle riunioni

Otto fusi orari coprono la maggior parte delle riunioni dei team distribuiti: Pacific (PST/PDT), Eastern (EST/EDT), Greenwich (GMT/BST), Central European (CET/CEST), India (IST), Japan (JST), Australian Eastern (AEST/AEDT) e New Zealand (NZST/NZDT). Memorizzare gli offset e il comportamento DST per questi fusi elimina il 90% del “aspetta, che orario è davvero?” avanti e indietro.

Il cheatsheet

Le trappole DST che rompono le riunioni ricorrenti

1. Finestre DST disallineate di tre settimane in primavera

Il DST USA inizia la seconda domenica di marzo. Il DST EU inizia l’ultima domenica di marzo. Per circa tre settimane ogni primavera, le riunioni USA-EU si spostano di un’ora rispetto al loro solito offset. Una chiamata alle 9:00 EST / 15:00 CET diventa 9:00 EDT / 14:00 CET — stesso orario NYC, diverso orario Berlino. Le app calendario di solito lo gestiscono correttamente; gli esseri umani che ricalcolano a mente di solito no.

2. Stagioni invertite nell’emisfero australe

Il DST australiano va da ottobre ad aprile. La Nuova Zelanda da fine settembre a inizio aprile. Entrambi sono oppostial calendario USA/EU. Quando New York “porta avanti” a marzo, Sydney sta per “tornare indietro.” Una chiamata regolare tra NY e Sydney si sposta due volte per ogni transizione USA/EU e due volte per ogni transizione AU/NZ — quattro aggiustamenti all’anno, non due.

3. India e Giappone non si spostano

Nessuno dei due osserva il DST. Dal punto di vista di un collega USA/EU, l’orario della riunione in India o Giappone si sposta due volte l’anno anche se lì non è cambiato nulla — è l’ufficio di casa che si è spostato, non quello remoto. Questo inganna la pianificazione basata su fogli di calcolo che assume un offset fisso.

4. Il gap di 24 ore tra LA e Sydney

L’ora del Pacifico e l’ora australiana orientale sono ~18-19 ore di distanza a seconda dello stato DST. La maggior parte delle giornate lavorative non si sovrappone affatto. La ristretta finestra di sovrapposizione:

• LA 15:00 = Sydney 8:00 del giorno successivo (inverno entrambi)
• LA 16:00 = Sydney 9:00 del giorno successivo (DST USA, inverno AU)

Quasi ogni chiamata LA-Sydney vive nella finestra pomeriggio LA / mattina Sydney. La direzione inversa (pomeriggio Sydney / mattina presto LA) è brutale per la parte del Pacifico.

Il calcolo delle finestre di riunione

Ore lavorative sovrapposte utili per le coppie più comuni:

Buone pratiche per team multi-fuso

• Scegli un fuso orario canonicoper tutti gli orari pubblicati. UTC è buono se il team è davvero distribuito; il fuso del gruppo più numeroso va bene altrimenti. Includi sempre l’offset (“15:00 UTC (11:00 EDT)”).
• Ruota il disagio delle riunioni.Se metà del team che partecipa è alle 8:00 e l’altra metà alle 20:00, scambia quale metà è quale ogni settimana alternata. Gli accordi a lungo termine che fissano sempre un team la sera bruciano quel team.
• Prediligi l’asincrono. Meno riunioni devono sovrapporsi, meno importa il calcolo dei fusi. Scrivi le decisioni; registra video aggiornamenti; tratta il tempo sincrono come la risorsa scarsa che è.
• Usa i nomi IANAnegli inviti al calendario (“America/New_York” non “EST”). I nomi IANA tracciano le modifiche DST; le abbreviazioni no. Le app calendario che memorizzano gli eventi per nome IANA gestiscono le transizioni DST correttamente senza modifiche manuali.
• Fai attenzione alla data. Una chiamata del venerdì alle 19:00 in California è le 12:00 del sabato a Sydney. I calendari gestiscono il calcolo della data — gli esseri umani che indovinano no.

Strumenti che aiutano davvero

Il convertitore di fuso orario di Convertitive visualizza qualsiasi orario in 28 zone principali con il DST gestito automaticamente dal database IANA del browser. L’ orologio mondiale dà una panoramica in tempo reale per scegliere le finestre di riunione. Le app calendario (Google Calendar, Outlook, Cal.com) ti permettono di visualizzare fusi orari secondari nel pannello laterale — attivalo una volta e dimenticalo.

Per il contesto concettuale su UTC, GMT e fusi orari IANA, vedi UTC vs GMT e la voce del glossario sul fuso orario IANA.

Analisi: pianificare un all-hands a quattro fusi

Una riunione aziendale di 60 minuti con gruppi a San Francisco (PST/PDT), New York (EST/EDT), Londra (GMT/BST) e Bangalore (IST). Data target: giovedì 7 maggio 2026.

• Stato DST il 2026-05-07:gli USA sono su PDT (UTC-7) / EDT (UTC-4). Il UK è su BST (UTC+1). L’India è UTC+5:30 durante tutto l’anno.
• Esprimi la riunione in UTC: 15:00 UTC.
• Orologio per gruppo:
  • San Francisco: 8:00 PDT (presto ma fattibile)
  • New York: 11:00 EDT (orario privilegiato)
  • Londra: 16:00 BST (tardo pomeriggio)
  • Bangalore: 20:30 IST (dopo cena — il prezzo di includere l’India in una chiamata centrata sugli USA)
• Formato invito al calendario (stile RFC 9557): 2026-05-07T15:00:00Z[Etc/UTC]con orari secondari elencati nella descrizione per ogni gruppo. Il client calendario visualizza automaticamente l’orario locale dell’utente; la Z esplicita rimuove l’ambiguità.
• Ruota il mese successivo: uno slot alle 7:00 UTC inverte il disagio — Bangalore alle 12:30 IST è ottimale, San Francisco a mezzanotte è brutale. Il cadenza all-hands dovrebbe ruotare affinché nessun gruppo sia sempre sacrificato.

Errori comuni

• Scrivere “EST” tutto l’anno.New York è su EDT (UTC-4) per ~8 mesi l’anno. Un invito al calendario che dice “15:00 EST” a luglio è silenziosamente le 16:00 EDT — o è sbagliato, a seconda di chi lo interpreta. Usa i nomi IANA (America/New_York) o UTC con offset.
• Confondere GMT e UTC.Differiscono di frazioni di secondo (gestione dei secondi intercalari). Per la pianificazione umana sono identici, ma Londra NON è su GMT in estate — è su BST. “GMT” in un invito di luglio è tecnicamente sbagliato.
• Calcolare manualmente attraverso la linea del cambiamento di data. Una riunione venerdì alle 16:00 a Sydney è venerdì alle 23:00 il giorno precedente a San Francisco. Il calcolo delle date a mano fallisce in entrambe le direzioni; lascia che il calendario lo elabori.
• Memorizzare gli orari degli eventi in ora locale.Le app che memorizzano “9:00” con un campo separato per il fuso si rompono nel momento in cui cambiano le regole DST del fuso (il database IANA rilascia ~5 aggiornamenti all’anno). Memorizza come istante UTC più il nome IANA originale; visualizza localmente.
• Asia/Calcutta vs Asia/Kolkata. Entrambi funzionano come alias, ma mescolarli nei calendari tra sistemi può causare problemi di sincronizzazione. Usa la forma canonica Asia/Kolkata.

Casi limite non coperti dal cheatsheet

• L’Arizona (per lo più) non osserva il DST.Phoenix è su MST tutto l’anno; la Nazione Navajo osserva il DST. Una riunione in “Mountain Time” può essere in due orari effettivi diversi a seconda della contea.
• Isola Lord Howe (Australia) usa un offset DST di 30 minuti — UTC+10:30 inverno, UTC+11 estate. Gli offset frazionari esistono in Terranova (UTC-3:30), Iran (UTC+3:30), Afghanistan (UTC+4:30), India (UTC+5:30), Nepal (UTC+5:45), Myanmar (UTC+6:30) e Isole Chatham (UTC+12:45).
• Il DST dell’UE potrebbe terminare in qualsiasi anno. Il Parlamento europeo ha votato nel 2019 per porre fine ai cambiamenti stagionali degli orologi; l’adozione è stata rinviata a tempo indeterminato. Quando accadrà infine, gli stati membri sceglieranno permanentemente l’ora solare o l’ora estiva — scelte diverse creeranno nuovi offset intra-UE.
• Voli nello stesso giorno che attraversano la linea del cambiamento di data.Un volo da Auckland a Honolulu atterra “prima” di essere partito in termini di orario locale. Le app calendario lo gestiscono; gli esseri umani che stimano i tempi di arrivo no.
• Timestamp storici.“9:00 a Berlino il 15 aprile 1942” richiede le regole storiche del fuso (CEST, con variazioni equivalenti al CEMT in tempo di guerra). IANA le codifica — l’aritmetica dell’offset UTC grezzo no.

Fonti: database IANA tz (2026a); Direttiva UE 2000/84/CE (disposizioni sull’ora estiva); US Energy Policy Act del 2005 (calendario DST USA moderno); RFC 9557 (IXDTF).