DjangoBot: #django-dev

mrts: cool - can you post that to a ticket?

jacobkm: sure

jacobkm: note that e.g. Beaker creates a new key as well on clear() (that's what I was talking about previously), see http://beaker.groovie.org/beaker/browser/beaker...

I still don't see a real need for that... but please think of the implications

jacobkm: #7515

mrts: thanks; I'll add it to my todo list

great

thanks

that's the second time buildbot encounters problems this week :o

Alex_Gaynor: trunk 2.4 sqlite was failling for some other reason before r7716

Yeah thats the intermittent template cache issue

If you look both 2.5 and 2.4 are having this domain issue

2.6 psycop is still going

5*

poor buildbot :o

seriously... it must be doing something strange because I never get these same failures locally.

I cannot see why changing tests in auth broke the sitename :o

Me neither, but it did

it has something to do with a test not properly cleaning up after itself: running the view tests all themselves don't cause a failure, but running the whole suite does cause that failure.

the PasswordResetTest ?

mrts: Typo in your docs, it says "in results" I think you meant "it results"

Alex_Gaynor: in result :), not in results... "as a result" perhaps

I'm not a native speaker, hence the somewhat inelegant phrasing... it's not an excuse though :)

Alex_Gaynor: please rephrase if you can

Sure

"This clears all session data. It results in an empty session, which is saving to the session store."

which is saved to the ...

saved*

Whoops

right, let's play it to the bone: "It results in an empty session that is saved to the session store." looks even more fluent

yes, no?

maybe I can't see it, but isn't there any option to tell runtests to not destroy the test database?

No idea, grammar's not really my strong suit :D

Alex_Gaynor: ?

dumb question: why is post_syncdb emitted at every test run?

(I mean, before every test runs)

Because I think django tears down and sets the db back up

but then the the database is correctly been teared down, the site object is created when post_syncb gets emited, so the test that is failling should have always been returning example.com except if when testing it should always return testclient

Err maybe not, I'm not that familiar with how the test framework works

the trouble seems to be near fixture loading.. if you disable the added fixture nothing bad happends :)

telenieko: yeah, I just hit the same thing

is any signal emitted when fixtures get loaded ?

jacobkm: when tests run, when a TestCase is ran, post_syncdb gets emitted, then the site object that was created, is not removed *until* the next TestCase is ran

So, if a TestCase runs, doctests have screwed Db's

that could explain this

runtests shows *all* test that failed, right?

yup

jacobkm: If you make contrib.auth.PasswordResetTest.test_email_found to fail, the other one succeeds

crazy

sure... found it when messing around with the fixture xD

so, the test is teared down differently depending on the result status ?

*maybe* this helps: django/contrib/sites/models.py:23

Is that SITE_CHACHE dict cleared on teardown ?

commenting line 23 solved the problem

maybe I said something really silly or you're seriously thinking about it :o

calling Site.objects.clear_cache() on the failling test solves that, so the problem is the SITE_CACHE thing :=)

So: I'm trying to sanely solve for storing DateTimeFields with time zones -- real time zones (e.g., "Americas/Chicago"), not just offsets (meaning my foray into using Postgres's backend support didn't go anywhere useful).

My current notion is using an extra "time_zone" argument on a DateTimeField, which is a string representing a relation (which might be on another model; useful when the time zone depends on a related object) ... but this is kinda weird since DateTimeField isn't a RelatedField, and fields generally don't get to look at their parent object instances

Is anyone else interested in this problem? I could use some alternate viewpoints/input ^_^

jacobkm: did you dig on the SITE_CACHE thing¿

jacobkm: would it be reasonable to create a "post-flushdb" signal, and make Sites connect to it to flush the cache when the db gets flushed ?

korpios: you prefer the route where the datetime object is aware of its timezone? i tend to go the other way and normalize.

brosner: dealing with multiple time zones simultaneously in one site ... can't do that

not sure i follow?

brosner: various pages need to be aware of exactly what timezone the user is in, relative to the object's timezone, and correct

yeah i implemented that on pinax using django-timezones

brosner: does that allow saving the timezone?

i leave that up to the user, see http://code.google.com/p/django-timezones/

we can't just save an offset or save only UTC, because we lose the original timezone, and that's important to us

err ... "Initial code. Nothing is functional at this point." ^_^

it is functioning.

just light on docs

lol okay was going by the commit message

heh

yeah at *that* time it wasn't :P

brosner: yeah, this doesn't cover what we need :-/ been banging my head against this for a bit already, sigh ^_^

hmm, but surely it just missing functionality that can be added?

my code goes both ways of users entering their timezone and returning their timezone

in terms of a datetime

thing is, we need the time zone *name* stored, since that's the only thing that understands things like DST switches when we pull it later and compare it up against a view in a different time zone ... we can't rely on settings.TIME_ZONE, we set that to UTC, because it's one site with views involving many time zones

my code doesn't assume how you stored the per user timezone just provides helpers to returning the localized datetime

yeah, that's not really the issue at hand ^_^

join #django-hotclub might be best for this discussion. there are other people in their that might help

hmmm

mm... #7514 lead to a worse bug :)

Does that patch solve the issue?

Alex_Gaynor: yes, all test pass

I'll file a bug later about Site.objects.get_current() ;)

korpios: maybe I'm being dense, but couldn't you relate the user to the timezone (as a model or choice or whatever)?

arien_: it has nothing to do with the user, actually ^_^

this isn't user preference

the objects you mention aren't (and don't have to be) "timezone-aware", right? I thought the problem was with the users.