Re: Django Design Czar

heya, Aha, excellent stuff. I must have missed that thread. Belated congrats to Idan =). Where is the best place to find out what's happening on the design side of things in Django? Haven't really heard much about it, Idan's blog (http://blog.gazit.me/) and Twitter

Re: Timezone-aware storage of DateTime

On Thu, Jun 30, 2011 at 1:38 PM, Daniel Swarbrick wrote: > Last year a customer's MySQL 5.1 server [...] I doubt it was your intention, but this kind of argument can *so* easily spiral into a flamewar. Certain things -- text editors, monospace fonts, operating

Re: MultipleObjectMixin and Pagination

Hi Andrew, On Jul 1, 9:12 am, Andrew Ingram wrote: > Hi All, > > I've been working with Django's class-based views a fair bit recently, > specifically to create some additional ones (dealing with formsets > mostly). I've been trying to inherit as much of the existing >

Re: Timezone-aware storage of DateTime

On Thu, Jun 30, 2011 at 2:10 PM, Aymeric Augustin < aymeric.augus...@polytechnique.org> wrote: > On 30 juin 2011, at 19:06, Daniel Swarbrick wrote: > > > On Jun 30, 6:31 pm, Ian Clelland wrote: > > > >> As a counterexample, I have needed to store wall-clock time as well as >

Re: Timezone-aware storage of DateTime

On Thu, Jun 30, 2011 at 3:10 PM, Aymeric Augustin wrote: > Strictly speaking, converting a naive datetime + a time zone to a "point in > time" (eg. UTC timestamp) isn't possible, because of DST: one hour doesn't > exist, and another one happens twice. In my

Re: Timezone-aware storage of DateTime

On 30 juin 2011, at 19:06, Daniel Swarbrick wrote: > On Jun 30, 6:31 pm, Ian Clelland 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

Re: Precedence in RequestContext processors

On Thu, Jun 30, 2011 at 3:51 PM, Michael Blume wrote: > First of all, I find it mildly odd that the context processor takes > precedence over the variable explicitly set, but that's obviously arguable. > Would it be possible for Django to kick up some kind of warning in

Precedence in RequestContext processors

Just tracked a regression in our site to the fact that I'd added a context processor to update the variable 'profile', and it was stomping one of our views that had an explicit context variable 'profile'. First of all, I find it mildly odd that the context processor takes precedence over the

Re: Timezone-aware storage of DateTime

On Jun 30, 7:45 pm, Andy Dustman wrote: > Since 4.0 came out in the late 1990s, isn't is possible that things > have improved somewhat over your dozen year gap of ignorance? > > (I'll stop feeding trolls now) No, it's a perfectly reasonable question that you ask. If I

Re: Timezone-aware storage of DateTime

On Thu, Jun 30, 2011 at 12:24 PM, Daniel Swarbrick wrote: > On Jun 30, 5:12 pm, Andy Dustman wrote: > >> Uh, no. -00-00 is specifically an illegal value in MySQL. Invalid >> dates are converted to -00-00 unless you are in strict mode, in

Re: Timezone-aware storage of DateTime

On Jun 30, 6:31 pm, Ian Clelland 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, >

Re: Timezone-aware storage of DateTime

On Thu, Jun 30, 2011 at 5:14 AM, Daniel Swarbrick < daniel.swarbr...@gmail.com> wrote: > On Jun 30, 11:06 am, Tom Evans 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

Re: Timezone-aware storage of DateTime

On Jun 30, 5:12 pm, Andy Dustman wrote: > Uh, no. -00-00 is specifically an illegal value in MySQL. Invalid > dates are converted to -00-00 unless you are in strict mode, in > which case they raise error conditions. The actual supported range is > from 1000-01-01 to

Re: Timezone-aware storage of DateTime

On Thu, Jun 30, 2011 at 4:51 AM, Daniel Swarbrick wrote: > The main difference between MySQL's "timestamp" field type and > PostgreSQL's "timestamp with time zone" field type (and indeed also > MySQL's "datetime" field type) is the date range that they support. >

Re: Customizable serialization. (Finally?)

Cool, thanks, all good points. Slight haitus working on this right now whilst I try to get my head around the right way to try to bring it more into line with the Forms API, but hoping to pick it up again once I've marshaled my thoughts. Obviously I'll keep the list updated if I do make more

Re: Timezone-aware storage of DateTime

On Thu, Jun 30, 2011 at 1:14 PM, Daniel Swarbrick wrote: > I personally find it relatively useless to know what the wall clock > time was when something happened in another timezone. Right, but this isn't DanielsWebFramework, we need to cover more than what you find

Re: Customizable serialization. (Finally?)

Hi! I put your code to good use in my project and have two minor suggestions: Make the signature of def get_related_serializer(self, key) like this: def get_related_serializer(self, key, obj): because the related serializer could also depend on obj (does for me). Secondly: the naming of

Re: Timezone-aware storage of DateTime

On Jun 30, 11:06 am, Tom Evans 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

Raising the minimum PostgreSQL version to 8.3

Hi, In ticket #16255 , changeset https://code.djangoproject.com/changeset/16423 raises the minimum supported PostgreSQL version to 8.2 However the PostgreSQL support policy, ,

Re: Forced password reset in django-admin

Hello again! > What you have suggested here **is** an invasive change, because it > requires changes to existing code paths. I think the way to measure "invasive" is by means of backwards compatibility. We do not change required arguments, return value or model fields... The view normally

Re: Timezone-aware storage of DateTime

On Thu, Jun 30, 2011 at 9:51 AM, Daniel Swarbrick wrote: > On Jun 29, 12:01 pm, Ryan McIntosh 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

Re: Timezone-aware storage of DateTime

On Jun 29, 12:01 pm, Ryan McIntosh 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