On Jun 30, 6:31 pm, Ian Clelland <clell...@gmail.com> wrote: > 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.
That is a good example, which I agree with. Although it sounds like more of a case for storing the date and time as separate fields (which is already feasible), since Python dates and times on their own have no tzinfo struct... only the combined datetime does (whether or not it includes hours/mins/secs components). -- 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.
