I bit the bullet and implemented passing the time zone name:
- via a parameter on PostgreSQL, SQLite and MySQL,
- through string interpolation on Oracle, with a regexp to validate the
value.
As a pre-requisite, the ORM needs to handle parameters in the SELECT clause:
https://github.com/aa
On Tue, Feb 12, 2013 at 3:35 PM, Aymeric Augustin
wrote:
>> Against the possible issue of non-recognition of UTC, I suggest using
>> '0:00' instead of 'UTC'.
>
> Thanks for looking into this problem!
>
> I tried '0:00' instead of 'UTC', and '+03:00' instead of
> 'Africa/Nairobi' with the same resu
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 pack
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 'BroadcastApp.setti
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 email
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).
G
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 developers" group.
To un
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 always fail with an ORA-0188
