On Thu, Jun 30, 2011 at 5:14 AM, Daniel Swarbrick < daniel.swarbr...@gmail.com> wrote:
> On Jun 30, 11:06 am, Tom Evans <tevans...@googlemail.com> wrote: > > > That is a domain specific assertion, I don't believe that is true in > > all cases. Typically, when we put things into the ORM, we expect to > > get the same things out again. If you consider viewing a timeline of a > > users activities, we might want to display the datetime of an event in > > both the viewing users timezone and the viewees timezone. If that > > information is discarded as irrelevant, then we could not do so. > > I personally find it relatively useless to know what the wall clock > time was when something happened in another timezone. I find it more > relevant to know what time it was for me, when said event occurred. In > most such cases, if the local time of the event was of importance, > then the *location* of the event would also be important, and probably > stored in the same DB model. If pytz is utilized, then we have a full > database of timezones at our disposal, and can derive from a location > what the local TZ was in that location at that particular moment in > time. More accurately, we can ascertain what the UTC offset was, and > whether DST was in effect - since those rules have changed through > history, and will continue to change. > While I agree with most of your points regarding database-storage of timestamps, the argument that wall clock time is 'relatively useless' certainly does not reflect my experience. As a counterexample, I have needed to store wall-clock time as well as time zones for future events, in scheduling applications. It is exactly because of the unpredictability of future DST changes (and, in very rare cases, wholesale time zone changes) that a one-time UTC conversion simply does not work for timestamps in the future. When an event is scheduled for a specific time, on a specific date in the future, then users expect that the web service will react at the appropriate wall clock time. An unforseen change in daylight saving time legislation should not have the effect of making the time in the database incorrect. Storing the time zone and wall clock time in the database allows the system to update the UTC timestamp appropriately whenever the Olson DB is updated. > > Western Samoa for example, will move to the other side of the > international date line on December 29th this year, effectively > jumping from a UTC-11 offset to a UTC+11 offset (skipping an entire > day in the process). Whilst such events are rare, it illustrates that > it is more useful to store the location of an event, plus have access > to the Olson tzdata DB, than to simply store a -11 or +11 offset > (which does not indicate whether DST was in effect). "Pacific/Samoa" > on the other hand can be looked up in tzdata, which will have an entry > stating that from 4 July 1892 until 29 December 2011, Samoa's UTC > offset was -11, at which point it changes to +11. > > For correct chronological sorting of events (which may occur in > multiple different timezones), or calculating deltas between > timestamps, life is a lot easier if you normalize to a common TZ, eg. > UTC, and only apply a local TZ offset when rendering the output to the > user. > Absolutely -- UTC is the only way to go in that situation, but it might be that the UTC timestamps are just a cache, generated from the local-time/TZ combination when needed. -- Regards, Ian Clelland <clell...@gmail.com> -- You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-developers@googlegroups.com. To unsubscribe from this group, send email to django-developers+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-developers?hl=en.
