Ciao a tutti,
vi segnalo la presenza di un BUG. Se si utilizzano colonne di tipo Datetime, essendo l’Italia un paese soggetto al cambio dell’orario (Ora Legale, Ora Solare), si crea una situazione che a mio parere è inammissibile, tutti i valori memorizzati in colonne di tipo Datetime cambiano il loro valore a seconda del cambio dell’orario. Questo fa si che viene a pardersi l’integrità del dato memorizzato. Vorrei segnalare il problema direttamente a Microsoft ma non riesco a trovare un contatto se non quello di carattere commerciale.
CONSIGLIO VIVAMENTE DI NON UTILIZZARE COLONNE DI TIPO DATETIME, PIUTTOSTO UTILIZZATE UNA COLONNA PER LA DATA E UNA PER L’ORARIO.
The biannual change to and from daylight saving time affects the way in which datetimes are displayed. For example, if you are located in central Europe, you are in the central European time zone and are using Central European Time (CET). During the winter the difference between CET and UTC is 1 hour. When you change to daylight saving time for the summer the difference is 2 hours.
This means that the local time representation of a UTC will vary depending on the time zone you are located in and whether you are using daylight saving time or not. Therefore, any datetimes that were entered during the winter will be converted and displayed differently after you have changed to daylight saving time for the summer. In other words, datetimes will not necessarily be displayed the same as when they were entered.
Pertanto anche se il suo comportamento fa decisamente schifo, dobbiamo tenercelo perchè funziona esattamente per come è stato sviluppato…
ti ringrazio per la tua risposta, non smetto di meravigliarmi nell’utilizzare questo prodotto…
Per risolvere il problema basterebbe creare una funzione che in fase di visualizzazione ti fa visualizzare l’ora salvata in relazione alla data in cui è stata salvata e non in base alla data in cui richiedo di vederla. Basterebbe solo questo per risolverlo.
Effettivamente nel mio post utilizzo inappropriatamente la “perdita d’integrità” dato che la data non cambia all’interno della base dati ma era riferita alla visualizzazione della data.
Proviamo a fantasticare un pò su questo che per loro non è un problema.
Immaginiamo che un’azienda utizza un sistema che quando si timbra l’ingresso/uscita dall’azienda vengono memorizzati data e ora su una colonna di tipo Datetime. Se oggi il mio capo effettua una verifica sui miei accessi dello scorso mese con sua grande meraviglia scopre che io sono entrato/uscito dall’azienda con un’ora di anticipo rispetto all’orario di lavoro previsto e questo è accaduto fino al giorno 28/11/2007.
Quindi io spiego al mio capo di spostare l’orario del suo pc di un’ora così da poter vedere i dati in maniera corretta e lui nota che dal 28/11/2007 in poi io sono entrato/uscito con un’ora di ritardo.
Resto del parere che sia un BUG, soprattutto in funzione del fatto che mi dici che funziona esattamente come è stato sviluppato. Quindi se una cosa è stata sviluppata male per me deve andar bene? Non ci sto. Continuo a scolsigliare l’utilizzo del Datetime.
E’ per questo che ho scritto questo post, o sistemano il problema oppure nussuno più utilizzerà colonne di tipo Datetime, poiché il loro comportamento è anomalo e può creare problemi (con questo funzionamento non ho idea per quale scopo si possa usare).
Se io ti dico che entro in azienda alle 8 del mattino e tu abiti in America, capisci che vado a lavorare alle 8 del mattino, mica ti metti a fare la conversione per vedere che ora è in America (magari lo fai, ma solo a livello di curiosità, non penso abbia importanza). E’ un pò come nella fisica, dipende dal punto di riferimento che scegli.
Speriamo che qualcuno si impegni affinché questo BUG venga risolto. Intanto, colgo l’occasione per consigliare nuovamente di NON USARE COLONNE DI TIPO DATETIME, USATE DUE COLONNE, UNA PER LA DATA E UNA PER L’ORA.