Post di Datapizza

Visualizza la pagina dell’organizzazione di Datapizza, immagine

139.018 follower

C’è chi odia i fusi orari e chi mente ⌛️ La gestione dei timestamp è un aspetto fondamentale dell’informatica, ma spesso crea grossi problemi agli sviluppatori. 🤯 Ma cos'è un timestamp? Si tratta di una sequenza che identifica univocamente un singolo momento nel tempo, e può essere memorizzato in diversi formati. I più famosi sono: 👉 Unix Timestamp: il numero di secondi trascorsi dal 1° gennaio 1970 (epoch Unix). È il formato più diffuso per la sua semplicità, ma non considera direttamente i fusi orari. 👉 ISO 8601: una rappresentazione più leggibile, come `YYYY-MM-DDTHH:MM:SSZ` che può includere informazioni sul fuso orario. Problemi dei fusi orari ❌ Un timestamp dovrebbe idealmente essere immutabile e universale, ma spesso le applicazioni necessitano di adattarsi ai fusi orari locali. Questo porta a problemi come: 👉 Variazioni stagionali: in Europa, per esempio, i fusi orari cambiano a seconda del periodo dell'anno: d'estate si utilizza il CEST (UTC+2), mentre d'inverno il CET (UTC+1). 👉 Ambiguità: la conversione tra fusi orari può portare a errori, specialmente quando si tratta di periodi di transizione come l'entrata o l'uscita dall'ora legale. Ecco alcuni suggerimenti per minimizzare i problemi legati ai timestamp e ai fusi orari: 👉 Utilizza UTC: Memorizza sempre i timestamp in UTC (il fuso orario di riferimento globale), convertendo in fusi orari locali solo quando necessario per l'interfaccia utente. 👉 Test approfonditi: Assicurati di testare le tue applicazioni in scenari che includano cambi di ora legale e fusi orari non standard. 👉 Documentazione: Mantieni una documentazione chiara su come la tua applicazione gestisce i timestamp e i fusi orari, per evitare malintesi e bug. #timestamp #datascience #ai

  • Nessuna descrizione alternativa per questa immagine
Domenico Sarsano

Back End Software Engineer at Engineering >>> SQL Server, Oracle, C#, Java, Node.js, PostgreSQL >>> Database, Stored Procedures and Back End Development: I can help!

7 mesi

Ci sono casi, quali una nave o un aereo che attraversano più fusi orari nei loro spostamenti, in cui è necessaria la persistenza sulla base dati dell'informazione relativa al fuso orario dell'osservatore presente sul mezzo di trasporto, e non dell'osservatore della base a terra, magari dall'altro capo del mondo. È quasi una questione di relatività galileiana, alla fin fine, quale punto di vista adottare, e non ce n'è uno più valido dell'altro. Quindi, per finalità di questo tipo, si può decidere di salvare data/ora in UTC, e a parte il fuso orario, oppure di salvare direttamente entrambe le informazioni nella data/ora o timestamp. Più che altro, a mio parere, è importante decidere, all'interno di un progetto, quale dev'essere lo standard e poi usare sempre quello, per evitare confusione e fraintendimenti.

Marco Stasi

IoT Architecture & Development Senior Manager at Haier Europe

7 mesi

Non ho mai messo in discussione l'utilizzo del timestamp UTC a DB, fino ad un recente caso che mi ha portato a rimetterlo in discussione come approccio, per il caso specifico. Il dado non è tratto, e sono certo che finiremo per scegliere il salvataggio di UTC, ma voglio sottoporre a questa audience di professionisti lo scenario per conoscere il vostro punto di vista. Un sistema di telemetria raccoglie dal campo dati di consumo energetico di un apparecchio (kWh) con periodo 5'. Fine ultimo: offrire all'end user la possibilità di consultare i consumi aggregati per ora (vista singolo giorno) per giorno (vista singolo mese), per mese (vista singolo anno) e per anno (vista storico anni). L'utente può interrogare il sistema da una qualunque TZ e questo non deve giocare alcun ruolo nell'aggregazione delle statistiche, che invece dipendono dalla TZ in cui è situato il dispositivo che genera il consumo. Tuttavia, non si può escludere a priori che il dispositivo venga spostato di TZ nella sua esistenza. A questo si aggiunge il DST a complicare le cose. Considerando di volersi avvalere di un DB timeseries per questo fine, salvare il timestamp in UTC in questo caso renderebbe l'interrogazione del dato molto complessa a runtime. Che ne dite?

Leonardo Lombardo

data & software professional

7 mesi

Una carezza a tutti quelli che conservano le date in formato locale 🚔🚔🚔

Alan Felice

Software Engineer

7 mesi

Pensa che "figo" lavorare a software per Artemis o qualche altro aggeggio che debba allunare e coordinarsi là. "Alla Nasa è stato affidato il compito di presentare un piano per la realizzazione dell'Ltc, il tempo coordinato lunare, necessario per tutte le attività delle future missioni il capo dell'Ufficio per le politiche scientifiche e tecnologiche (Ostp) della Casa Bianca ha incaricato l'agenzia spaziale di collaborare con altre parti del governo americano per elaborare entro la fine del 2026 un piano utile a stabilire ciò che sarà necessario per quello che è stato chiamato il Coordinated Lunar Time (Ltc). Adottare un fuso orario lunare standard, con la nuova era dell'esplorazione lunare, sarà fondamentale per coordinare tutte le attività." La parte ancora più "gustosa": "Più specificamente un orologio sulla Luna inizialmente sincronizzato con uno sulla Terra sarebbe avanti di circa 56 microsecondi dopo 24 ore" 🤕 https://www.wired.it/article/luna-fuso-orario-pianeti-nasa/

Irvin Dominin

Responsabile BUILDER WEB (R&S) presso Sistemi S.p.A. | HUB e cloud Sistemi | C# and JS lover

7 mesi

Intanto in Australia

  • Nessuna descrizione alternativa per questa immagine
Moreno Marasco

Country Manager ▪️ Direttore Marketing ▪️ Membro CdA ▪️ General Management ▪️ Pilota Privato 🛩️ | P&L | Digital Strategy | eCommerce | MBA

7 mesi

È un post per sviluppatori a km zero? 😁 Il problema principale non sono i fusi orari in sé, bensì l'ora legale. Quindi sui sistemi i dati devono necessariamente essere memorizzati in UTC, diventa poi un mero esercizio di visualizzazione determinare l'ora locale corretta (che non va mai intesa come offset corrente, bensì storico, per via dell'ora legale), mai di memorizzazione. Non è solo questione di persistenza dati: a monte, nei trasporti internazionali tutte le comunicazioni sono in UTC. Fu previsto da ICAO per evitare ambiguità, anche perché la distribuzione dei fusi orari è tutto fuorché lineare.

Diego Dorola

CEO @ AM Digital Life | | CEO Co-Founder @ Madist | CTO @ Blazar Group

7 mesi

Purtroppo ci sono “pessimi” casi dove è necessario salvare l’ora locale ed in questo il cloud costringe a forzature ancor peggiori, perché ragiona in UTC. Un sacco di calcoli/ricalcoli per garantire che la data iniziale venga mantenuta. In alternativa dovrei salvare in UTC più il timezone di riferimento per conversioni. i fusi… fondono…

stefan S.

Freelance. EDA software dev. for VLSI / ASIC Previously Distinguished Member of Technical Staff at Micron Technology.

7 mesi

IMHO: Timestamps e altre informazioni temporali devono essere in UTC. tutti i calcoli devono essere fatti dopo aver convertito ore locali in UTC. quando si presentano dati temporali si puo' usare l'ora locale ma sempre seguita da una sigla che permetta di calcolare la corrispondente ora UTC. (14:24 CEST, per esempio, oppure 2:27 PM EDT)

Luca Crisafulli

Sviluppatore Full Stack .NET, Web Blazor e Mobile MAUI

7 mesi

Nel DB ci devono essere presenti SOLO date "Zulu". Poi come esse vengano rappresentate a video dipende dalla "locale" del client. Risolto.

Vedi altri commenti

Per visualizzare o aggiungere un commento, accedi