Răspunsul, ca întotdeauna, este "depinde".
Depinde de ce descrieți cu timpul și de modul în care ați fost furnizați datele.
Cheia pentru a decide cum să păstrați valorile de timp este să decideți dacă pierdeți informații prin abandonarea zonei de fus orar și să nu uitați utilizatorii.
Există beneficii clare în stocarea datelor într-un time_t UTC - este un singur int, care permite o sortare rapidă și o stocare ușoară.
Văd problema ca fiind defalcată în domenii specifice:
- Date istorice
- Viitoare, date pe termen scurt
- Viitoare, date pe termen lung
Cu următoarele subclase pe fiecare:
- Sistemul furnizat
- Utilizator furnizat
Să ne uităm la ele unul câte unul.
System Provided: I would recommend running systems in UTC, then you avoid the timezone problem and again, no information loss is seen (it's always UTC).
Historical Data: These are things like system log files, process statistics, tracing, comment dates/times, etc. The data isn't going to change, and the timezone descriptor isn't going to change retroactively. For this type of data, there is no information lost by storing the information in UTC regardless of the timezone it was provided in. So, drop the timezone.
Future, Long Term Data: These are events that are either far enough in the future or will keep happening. If they are kept around long enough, the timezone descriptors are guaranteed change. A good example of this type of data is, "The Weekly Management Meeting". This is data that is entered once, and expected to keep working into perpetuity. For these values, it is important to determine if it is system or user provided. For user-provided data, the time should be stored with the creator's timezone, anything else results in information loss. This information loss becomes apparent when the timezone definition changes and the time is displayed to the creator as having an entirely different value!
După cum a indicat Bwooce, există o anumită confuzie în care creatorul și spectatorul se află în diferite fusuri orare. În acest caz, m-aș aștepta ca aplicația să indice ce valori de timp s-au mutat din cauza unei treceri de fus orar de la locațiile lor anterioare.
Future, Short Term Data: This is data that is quickly going to become historical, or is only valid for a short period of time. Examples could be interval timers, rating transitions, etc. For this data, since the likelihood is low that the definition will change between the creation of the value and the time it becomes historical, it might be possible to get away with dropping the timezone. However, I have found that these values have a bad habit of becoming "Future, Long Term Data".
Odată ce ați decis să stocați fusul orar, trebuie să aveți grijă de modul în care este stocată.
- Nu păstrați fusul orar ca decalaj sau descriptorul complet.
Dacă stocați o fus orar ca compensare, ce faceți dacă se modifică fusul orar? Treci prin sistem și faci o schimbare de pătură pe datele existente? Dacă faceți acest lucru, ați făcut acum toate valorile istorice incorecte. Exemple bune ale acestei erori sunt Oracle și iCal. Oracle stochează informațiile de fus orar ca o compensare de la UTC, iar iCal include descriptorul complet pentru fusul orar de creare.
Aceasta permite modificarea definiției zonei de fus orar fără a fi nevoie să modificați valorile existente pe care le aveți. Aceasta face ca sortarea să fie mai dificilă, deoarece orice index care este generat poate fi nevalid dacă datele de fus orar se modifică.
Dacă dezvoltatorii continuă să stocheze totul în UTC, indiferent de fusul orar, vom continua să vedem problemele pe care le-am văzut cu ultimul lot de schimbări de fus orar.
La o singură organizație, secretarii au trebuit să tipărească calendarele pentru echipele lor înainte de ziua de economisire a zilei și apoi să le tipărească din nou după schimbare. În cele din urmă, au comparat cele două și au re-creat toate întâlnirile care s-au mutat. Desigur, au ratat mai multe, și au existat câteva săptămâni de durere până când sa ajuns la data de vechime a luminii de vară, iar vremurile au devenit din nou corecte.