Hello,
I'm glad to announce that the time zone support branch is ready for review.
Review the changes:
https://bitbucket.org/aaugustin/django/compare/..django/django
Clone the branch: hg clone https://bitbucket.org/aaugustin/django
Play with the demo app: hg clone https://bitbucket.org/aaugustin
Hi Aymeric,
Finally got around to this! My review follows. I didn't follow the
original discussions very closely, so forgive any questions that have
been answered already. On the other hand, the code and comments probably
ought to answer the kind of questions I have, without needing to search
mail
Hi Luke,
Thanks for the review! I've updated the branch with your suggestions.
Here are a few comments -- when I have something to say other than
"fixed, thanks".
2011/11/8 Luke Plant :
> == django/contrib/admin/util.py ==
>
>> elif isinstance(field, models.DateField):
>> return format
On 10/11/11 07:46, Aymeric Augustin wrote:
>> I haven't actually reviewed any of the test code - I ran out of energy,
>> and test code is so dull, sorry!
>>
>> I did run coverage for the tests and found:
>>
>> - without pytz installed, the new LocalTimezone class
>
> You apparently ran out of ene
Just in case you were waiting for a reply, I've read your response and
everything seems good to me.
Luke
On 10/11/11 07:46, Aymeric Augustin wrote:
> Hi Luke,
>
> Thanks for the review! I've updated the branch with your suggestions.
>
> Here are a few comments -- when I have something to say o
On Nov 1, 4:58 pm, Aymeric Augustin
wrote:
> I'm glad to announce that the time zone support branch is ready for review.
I did a simple performance test on PostgreSQL (fetch 1000 objs with
datetime field) and could not see any real performance regressions. I
did the same for template rendering, a
Hi Anssi,
2011/11/18 Anssi Kääriäinen
> So, at least according to this simple test there is nothing to
> worry about performance-wise.
>
Thanks for the performance tests! They were still on my TODO list.
> This part of the documentation raises one question:
> """
> Unfortunately, during DST
On Nov 18, 5:31 pm, Aymeric Augustin
wrote:
> Hi Anssi,
>
> 2011/11/18 Anssi Kääriäinen
>
> > So, at least according to this simple test there is nothing to
> > worry about performance-wise.
>
> Thanks for the performance tests! They were still on my TODO list.
The tests could be better... It mi
2011/11/18 Anssi Kääriäinen
> My point is that it would be very useful to know you are actually
> using aware datetimes internally. Especially when migrating an old
> project to use this feature, it is easy to miss some places that do
> not use aware datetimes. And you might find it out when you
On 18 November 2011 16:57, Anssi Kääriäinen wrote:
> My point is that it would be very useful to know you are actually
> using aware datetimes internally. Especially when migrating an old
> project to use this feature, it is easy to miss some places that do
> not use aware datetimes. And you might
Le 1 nov. 2011 à 15:58, Aymeric Augustin a
écrit :
>
> There is only one outstanding issue that I know of. `QuerySet.dates()`
> operates in the database timezone, ie. UTC, while an end user would expect it
> to take into account its current time zone. This affects `date_hierarchy` in
> the ad
I spent the better part of the day struggling with Oracle and unsurprisingly
nothing works :(
Given this model:
class Event(models.Model):
dt = models.DateTimeField()
I'm trying to implement this query with time zone support enabled:
Event.objects.filter(dt__month=1)
That's a
On Tue, Feb 12, 2013 at 2:25 PM, Aymeric Augustin
wrote:
c.execute("""SELECT "DT" FROM "TIMEZONES_EVENT" WHERE EXTRACT(MONTH FROM
CAST((FROM_TZ("DT", 'UTC') AT TIME ZONE (:arg)) AS DATE)) = 1""",
['Africa/Nairobi']).fetchall()
> Traceback (most recent call last):
> File "", line
On Tue, Feb 12, 2013 at 3:06 PM, Ian Kelly wrote:
> On Tue, Feb 12, 2013 at 2:25 PM, Aymeric Augustin
> wrote:
> c.execute("""SELECT "DT" FROM "TIMEZONES_EVENT" WHERE EXTRACT(MONTH FROM
> CAST((FROM_TZ("DT", 'UTC') AT TIME ZONE (:arg)) AS DATE)) = 1""",
> ['Africa/Nairobi']).fetchal
Le 12 févr. 2013 à 23:12, Ian Kelly a écrit :
> On Tue, Feb 12, 2013 at 3:06 PM, Ian Kelly wrote:
>>
>> I encounter the same bug in Oracle 10g XE. I tried it also on an 11.2
>> database, and it seemed to work, but I ran into a different issue:
>> neither of the time zones 'Africa/Nairobi' nor
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
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
Hello,
As noted by Luke in his review of the time zone support branch, there's a large
overlap between django.utils.tzinfo and django.utils.timezone. See the excerpt
of our discussion below. I prepared a pull request for this long overdue
refactoring.
https://github.com/django/django/pull/1601
19 matches
Mail list logo
