On Thu, Jun 30, 2011 at 9:51 AM, Daniel Swarbrick <daniel.swarbr...@gmail.com> wrote: > On Jun 29, 12:01 pm, Ryan McIntosh <thebigsl...@gmail.com> wrote: >> Is that a crutch of your database? It isn't something I would ever live >> with. All the *sql database servers I hate have an idea of what a >> timestamp+offset is. Django should leverage this. IMHO, no such field >> should exist in the underlying database but for ticks since epoch if tzs >> aren't supported... Everything useful should be derived if necessar... > > I think there is a misunderstanding of UTC and timezones in general in > this thread. If TZ-aware datetime handling were to be added to Django, > it would almost certainly require the pytz module. That module > contains sufficient information to convert any UTC timestamp to any TZ > in the world, dating back sometimes as far as a couple of hundred > years, and reaching forward in the future (pending any future changes > of DST rules for a particular timezone). > > It is redundant to store the original TZ in a clip-on field, if the > original input is properly handled. Take for example the following > three timestamps: > > '1969-07-20T20:17:40+00:00' > '1969-07-20T16:17:40-04:00' > '1969-07-20T21:17:40+01:00' > > They are all the same moment in time. The fact that they are expressed > as different local times is only relevant to the observer. Which one > will a (half-decent) DB engine store? The UTC one. Which one do I want > to show my users? Well, that depends which timezone they live in... > NOT which timezone the data was input. >
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 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. 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.
