Le 13 févr. 2013 à 20:54, Ian Kelly a écrit :
> I only meant that the final SQL should use '0:00' instead of
> 'UTC' to guard against databases that for whatever reason do not have
> a UTC time zone definition, such as the one that I found. Otherwise
> the query would
On Tue, Feb 12, 2013 at 10:21 AM, Val Neekman wrote:
> If I had to choose between GeoDjango and South as a core package, I'd go with
> South for sure.
FTR, that's in the works.
Jacob
--
You received this message because you are subscribed to the Google Groups
"Django
Hi. You are getting problems with your static files.
There is a lot of posts and tutorials you can find on Google about this
topic.
Django manage static files only for Development (setting them correctly on
settings.py) , and on production you should use a server for them (apache
for example).
Please ask questions about using Django to django-users. This list is for
discussion of the development of Django itself.
Thanks,
Karen
--
You received this message because you are subscribed to the Google Groups
"Django developers" group.
To unsubscribe from this group and stop receiving
Hi
I am new to Django. When i run my Django project i get 0 errors. But when i
run my browser with the "http://127.0.0.1:8000/;, i get the following
console log. Please help me and plenty thanks in advance.
*Console log*
0 errors found
Django version 1.4.3, using settings
Yeah, it's amazing that we have GeoDjango included as I'm using it right now.
However I can fall back to geopy and still getaway with rough acceptable
estimates with limited scope and capability which I'm fine with. (In my use
case)
If I had to choose between GeoDjango and South as a core