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. 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. > I could certainly see what you are describing as a specific field - a > NormalizedDateTimeField, which explicitly normalizes to UTC for > storage and to settings.TZ for display - but it shouldn't be the only > way. This is exactly what Postgres is doing internally - normalizing to UTC. It does not, I repeat, does NOT store the TZ. The client connection's TZ is merely dynamically added/subtracted to/from the normalized UTC timestamps coming from the storage backend. The fact that MySQL's datetime field type doesn't normalize to UTC is a question for the MySQL developers... maybe they all came from the same village, and had no need for timezones. > > Cheers > > Tom -- 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.
