Re: Time zone (Django 1.4) questions

[Aymeric Augustin]

Hi Klaas,

Le mardi 12 juin 2012 13:13:14 UTC+2, Klaas van Schelven a écrit :
>
> 1] Migration of non-UTC to UTC: is there any script / best practice 
> available? 
>
Django's documentation mentions that all data should be converted to UTC 
> when switching to USE_TZ=True. See: 
> https://docs.djangoproject.com/en/dev/topics/i18n/timezones/#other-databases
> This is a rather concise remark. Are there any scripts/tricks available to 
> do this in "one go", and to be able to easily do the same conversion in 
> development and production.
>

I assume it's possible to walk through all models and look for 
DateTimeFields, then perform the conversion. However performance must be 
taken into account — your database may not like large updates, and handling 
of special cases too. As you know, conversions from naive local time to UTC 
may fail (during the autumn DST transition).

I haven't written that script and I don't know anyone else who has. No 
promises, but since you need it, I may find the motivation to write it.

2] The meaning of Queryset filtering: am I correct to understand that 
> operations on the DB are now always interpreted in UTC?
> I.e. any direct comparisons to datetime? But also the __month __year 
> quasi-fields?
> This does not appear to be documented explicitly anywhere, at least not in 
> the queryset documentation itself.
> And should we not consider this a bug since a naive use of these is 
> explained in almost every single Django beginners toturial?
>

Yes, operations performed within the DB itself are in UTC, and as a 
consequence __day, __month, __year probably don't do what you expect when 
USE_TZ = True.

The most recent state of my thoughts on this problem is here: 
https://code.djangoproject.com/ticket/17260#comment:14
 

> 3] Since date and datetime are radically different concepts (respectively 
> a point in time and a calendaring concept) what is the meaning of
> auto_now and auto_now_add on a DateField? Is the current Timezone or the 
> default Timezone used? Should this not be documented?
>

The behavior hasn't changed, which means the default time zone is used.

Specifically, the implementation calls `datetime.date.today()`, which 
relies on the process' time zone. Under Linux it's defined by the TZ 
environment variable, which is set to settings.TIME_ZONE. Under Windows I 
think it's always the system time zone.

Generally speaking, the current implementation of auto_now and auto_now_add 
has some issues. For instance QuerySet.update() won't change the value of a 
field with auto_now=True. Therefore, I strongly recommend using 
`default=timezone.now` or a custom save() function, as it is more 
predictable.

Best regards,

-- 
Aymeric.

-- 
You received this message because you are subscribed to the Google Groups 
"Django users" group.
To view this discussion on the web visit 
https://groups.google.com/d/msg/django-users/-/9PufMWWjvhwJ.
To post to this group, send email to django-users@googlegroups.com.
To unsubscribe from this group, send email to 
django-users+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-users?hl=en.

Re: Time zone (Django 1.4) questions

[Aymeric Augustin]

Le jeudi 21 juin 2012 13:36:53 UTC+2, Aymeric Augustin a écrit :
>
> I haven't written that script and I don't know anyone else who has. No 
> promises, but since you need it, I may find the motivation to write it. 
>

Here you go: https://gist.github.com/2971450

The script is designed to handle advanced cases (inherited models, proxy 
models) but I haven't tested it. I've mentioned all the failure modes I 
could imagine in the disclaimer.

Let me know if it works for you!

Best regards,

-- 
Aymeric.

-- 
You received this message because you are subscribed to the Google Groups 
"Django users" group.
To view this discussion on the web visit 
https://groups.google.com/d/msg/django-users/-/NgCN-MDc_nEJ.
To post to this group, send email to django-users@googlegroups.com.
To unsubscribe from this group, send email to 
django-users+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-users?hl=en.

Re: Time zone support enabled in Django 1.4, yet "Django does not support timezone-aware times"

[Aymeric Augustin]

Le mardi 22 mai 2012 02:57:05 UTC+2, Arthur a écrit :
>
> I recently upgraded one of my machines to Django 1.4 to patch a bug 
> related to the use of PostGIS 9.1. I read the documentation on the new 
> support for time zones and added USE_TZ=True to my settings.py file. 
> Nonetheless, when I attempt to load data into my PostGIS database in one of 
> the following ways, I receive a ValueError: Django does not support 
> timezone-aware times. The full traceback is posted at the end. 
>

Hi Arthur,

The error message is about "timezone-aware times", not "timezone-aware 
datetimes". Your code must be creating a timezone-aware time object 
somewhere. This is quite a pathological type and it isn't supported by 
Django.

This limitation is briefly mentioned at the bottom of this 
section: 
https://docs.djangoproject.com/en/dev/topics/i18n/timezones/#naive-and-aware-datetime-objects

Sorry for the late answer,

-- 
Aymeric.

-- 
You received this message because you are subscribed to the Google Groups 
"Django users" group.
To view this discussion on the web visit 
https://groups.google.com/d/msg/django-users/-/0bzgv4H2WsUJ.
To post to this group, send email to django-users@googlegroups.com.
To unsubscribe from this group, send email to 
django-users+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-users?hl=en.

Re: django.contrib.humanize naturaday not working with USE_TZ = True

[Aymeric Augustin]

Le dimanche 13 mai 2012 04:33:33 UTC+2, James Zheng a écrit :
>
> has anyone else run into the problem below?


Hi James,

Since you're talking about USE_TZ, I suppose you're using Django 1.4. But 
the code you're quoting no longer exists in that version:
https://github.com/django/django/commit/9b1cb755a28f020e27d4268c214b25315d4de42e#diff-3
 

That said, this appears to be a bug in Django. I've created a ticket:
https://code.djangoproject.com/ticket/18504

Best regards,

-- 
Aymeric.

-- 
You received this message because you are subscribed to the Google Groups 
"Django users" group.
To view this discussion on the web visit 
https://groups.google.com/d/msg/django-users/-/gNvXW6g6otEJ.
To post to this group, send email to django-users@googlegroups.com.
To unsubscribe from this group, send email to 
django-users+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-users?hl=en.

Re: No timezone support for TimeField?

[Aymeric Augustin]

Le mardi 31 juillet 2012 22:34:46 UTC+2, Tejinder Singh a écrit :
>
> Django 1.4 does not store aware times for TimeField, it only does for 
> DateTimeField. Its really annoying, as python datetime.time object does 
> support TZINFO just like datetime.datetime objects. I wonder if it is a 
> bug? Btw i have tested it on postgres 9.1 database server


This is a design choice documented here:
https://docs.djangoproject.com/en/dev/topics/i18n/timezones/#naive-and-aware-datetime-objects
(see the last note of this section).

Sorry for answering so late.

-- 
Aymeric.

-- 
You received this message because you are subscribed to the Google Groups 
"Django users" group.
To view this discussion on the web visit 
https://groups.google.com/d/msg/django-users/-/OYB9qpXk5d0J.
To post to this group, send email to django-users@googlegroups.com.
To unsubscribe from this group, send email to 
django-users+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-users?hl=en.

Re: how to use timezones for datetime fields that are foreign keys in admin interface

[Aymeric Augustin]

Le lundi 3 septembre 2012 02:48:24 UTC+2, dalupus a écrit :
>
> On the item list screen however the datetime is not formated and seems 
> to be in utc format like so: 
> 2012-09-03 00:28:21.664176+00:00 
> so it appears it is not adjusting to display the field in the users 
> timezone. 
>
> Any ideas how to get around this? 
>

In Django 1.5, you will be able to use django.utils.timezone.localtime().
https://docs.djangoproject.com/en/dev/ref/utils/#django.utils.timezone.localtime

Unfortunately, there's no such built-in utility in Django 1.4.

-- 
Aymeric.

-- 
You received this message because you are subscribed to the Google Groups 
"Django users" group.
To view this discussion on the web visit 
https://groups.google.com/d/msg/django-users/-/DnEjiPSxvmkJ.
To post to this group, send email to django-users@googlegroups.com.
To unsubscribe from this group, send email to 
django-users+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-users?hl=en.

Maintenance on djangoproject.com tomorrow

[Aymeric Augustin]

Hi folks,

We've scheduled maintenance operations on djangoproject.com tomorrow, starting 
at 09:00 UTC.

The website and the docs may be temporarily unavailable.

Please use the mirror of the docs at Read The Docs in the meantime: 
http://django.readthedocs.org/

Thanks,

-- 
Aymeric.



-- 
You received this message because you are subscribed to the Google Groups 
"Django users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-users+unsubscr...@googlegroups.com.
To post to this group, send email to django-users@googlegroups.com.
Visit this group at http://groups.google.com/group/django-users?hl=en.
For more options, visit https://groups.google.com/groups/opt_out.

Re: Understanding Django transactions

[Aymeric Augustin]

Hi Michael,
 
>
> *Django 1.5:*
>

>- The database-level auto-commit is turned OFF.
>
> Yes. 

>
>- SQL standards dictate that every query opens a transaction if one 
>does not already exist. This happens regardless of the database's 
>auto-commit setting.
>
> Yes, this is required by PEP 249 and taken care of by the database 
adapter. 

>
>- After each Django ORM operation (read or write), Django commits this 
>open transaction. This emulates the database-level auto-commit.
>
> No, transactions are only committed after write operations, so it isn't 
exactly like database-level autocommit. 

>
>- Transaction decorators cannot be nested. When one is opened, any 
>previous transaction will be committed.
>
>  Not necessarily. It's complicated. It depends on the previous state (auto 
/ managed), the current state (auto / managed) and the dirty flag.

I never understood the logic. Your best chance is to read the source if you 
really need to know how it works.

>
>- When executing raw SQL (with a database cursor), Django marks the 
>current transaction as dirty but does not issue a commit. If data changes 
>were made then they need manually committing. *Why do the 
> **docs*
>* say that you only need to commit the change if data was changed? If 
>the transaction is marked as dirty regardless of a read or a write, would 
>it not always need committing or rolling back to ensure the transaction is 
>properly closed by the end of the connection?*
>
> In Django 1.2 and earlier, the connection wasn't marked dirty on raw SQL 
operations. If you didn't commit and you didn't perform any other writes 
until the end of the query, Django would issue a rollback.

In Django 1.3-1.5, I'm not sure what happens exactly. I believe the 
transaction management will always issue a commit or a rollback before the 
connection is aborted and closed by the request_finished signal, but I 
could be wrong.

Honestly, when I rewrote transaction management, no one understood how it 
interacted with the dirty flag. So I can't answer this question and I don't 
think anyone else can. Once again, read the source if you need to know how 
it works in a specific case.

>
>- Setting TRANSACTIONS_MANAGED to True stops Django from sending any 
>commits after ORM operations. The database-level auto-commit is still 
>disabled.* With this setting, using any Django ORM read or write 
>operation (all wrap**ped in `transaction.commit_on_success`) fails 
>with TransactionManagementError('This code isn't under transaction 
>management'). Is this expected?*
>
> I have no idea.

>
>
> *Django 1.6:*
>
>- The database-level auto-commit is turned ON. 
>- Every database operation via the ORM will be committed using the 
>database's auto-commit, including any custom SQL executed with the 
> database 
>cursor. 
>- The `atomic` decorator / context manager either starts a new 
>transaction, or creates a new savepoint if it's nested within an existing 
>transaction. They are committed as long as no exception is raised. 
>- If ATOMIC_REQUESTS is specified in the database config, all views 
>are wrapped in `atomic`, unless it's wrapped in `non_atomic_requests`.
>
> Yes, these four sentences are correct. 

>
>- If you set AUTOCOMMIT to False in a database configuration, this 
>will disable the database-level auto-commit. All DB reads and writes will 
>need manually wrapping in transactions. *The 
> **docs*
>* say that with this disabled, Django won't perform any commits. Does 
>this mean that the `atomic` decorator won't work properly and you have to 
>use the underlying database library to handle transactions? In 1.6 it 
> would 
>appear that Django never performs a commit outside of `atomic`, so I'm 
>confused by this comment!* 
>
> First, it's extremely unlikely that you will ever need to set AUTOCOMMIT 
to False. This is only useful if you want to implement your own transaction 
management, and I don't know anyone who's done that, nor a use case for 
doing that. I'd be surprised if this discussion was relevant to a single 
person on this mailing list (but I've been surprised before!). Also, your 
link goes to the 1.5 docs, not the dev docs. This may have confused you.

Anyway, in this scenario, `atomic` will work as expected. When autocommit 
is off, you're always in a transaction, and as a consequence `atomic` uses 
savepoints to guarantee atomicity; it'll never commit. You have to call 
transaction.commit() at some point to save changes.

I hope that helps,

-- 
Aymeric.

PS: If you weren't at DjangoCon Europe, you might want to check my talk on 
this topic. Slides are at 
http://static.myks.org/data/20130517-DjangoCon-Transactions.pdf and the 
vid

Django Debug Toolbar supports Python 3 - beta testers wanted!

[Aymeric Augustin]

Hello,

I just upgraded the Django Debug Toolbar to support Django 1.5 and Python 
3. Since there hasn't been a release in a long time, and since support for 
Python 3 required rather extensive changes, I would really appreciate if 
you could try it before we make an official release on PyPI in a few days.

To install the development version, run:

$ pip uninstall django-debug-toolbar# in case it's already installed
$ pip install django-debug-toolbar==dev

Please report regressions and bugs to 
https://github.com/django-debug-toolbar/django-debug-toolbar/issues.

Thanks for your help!

-- 
Aymeric.

-- 
You received this message because you are subscribed to the Google Groups 
"Django users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-users+unsubscr...@googlegroups.com.
To post to this group, send email to django-users@googlegroups.com.
Visit this group at http://groups.google.com/group/django-users.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-users/90deb1c6-3bca-45ec-90d2-6663a7a03829%40googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

Django Debug Toolbar 1.0 beta released

[Aymeric Augustin]

Hello,

I'm happy to annonce that we're almost ready to release version 1.0 of the 
Debug Toolbar! Now we need your help to try the beta:
https://github.com/django-debug-toolbar/django-debug-toolbar/releases/tag/1.0-beta

The documentation is available on Read the Docs — make sure you read the 
"latest" version as there are many changes since 0.11:
http://django-debug-toolbar.readthedocs.org/en/latest/

Note that the setup process is different from previous versions:
http://django-debug-toolbar.readthedocs.org/en/latest/installation.html#quick-setup

Please report issues on GitHub:
https://github.com/django-debug-toolbar/django-debug-toolbar/issues

If no major problems are found, we'll release 1.0 in one week.

Here are the main changes from version 0.9.x and earlier. (Versions 0.10 
and 0.11 were transitory versions leading to 1.0; they were released to 
validate some choices before committing to support them for the lifetime of 
1.x.)

- Panels are now rendered on demand, solving the "20MB HTML page" problem
- Panels can be individually disabled from the frontend, in case a panel 
degrades performance severely on a page
- Interception of redirects can be toggled from the frontend
- The handle can be dragged along the right side, in case it hides exactly 
the part of the page you're working on :-) 
- Static files are managed with django.contrib.staticfiles, solving a 
series of URL-related issues
- The setup process was rewritten, to provide a simplified automatic setup 
and an optional explicit setup
- Panels and settings received shorter or better names
- A stable API for third-party panels is documented
- The core of the toolbar was simplified drastically and almost all the 
code was refactored into panels
- The toolbar was made compatible with all current versions of Django and 
Python, including Python 3.
- The test suite was expanded and gained Selenium tests
- Dozens of bugs were fixed

I hope you'll like it!

-- 
Aymeric.

-- 
You received this message because you are subscribed to the Google Groups 
"Django users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-users+unsubscr...@googlegroups.com.
To post to this group, send email to django-users@googlegroups.com.
Visit this group at http://groups.google.com/group/django-users.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-users/2d498dbe-3880-4986-9dc6-a4f7a68ed1b6%40googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

Re: Django Debug Toolbar 1.0 beta released

[Aymeric Augustin]

On 16 déc. 2013, at 12:33, kamagatos  wrote:

> we should start thinking about a way to catch and display every ajax/json 
> responses. because more and more applications are becoming ajax ready and 
> they use front-end frameworks like angularjs or backbone to deal with getting 
> stuff on the backend.

Several people have already thought about it, and some have written code: 
https://github.com/django-debug-toolbar/django-debug-toolbar/pull/356. But as 
I’m not using the toolbar myself — I merely modernized it because I believe 
it’s an important component of the Django ecosystem — I’m lacking motivation to 
write that feature.

Fortunately, in version 1.0, the core of the toolbar has been slimmed down 
drastically; almost everything is implemented in panels. You can implement the 
feature you’re describing as a third-party panel, without any changes to the 
toolbar itself. If you write such a panel and it works well, then we could 
discuss merging in the toolbar.

The public API for panels is documented here: 
http://django-debug-toolbar.readthedocs.org/en/latest/panels.html#api-for-third-party-panels.
 I hope this helps!

-- 
Aymeric.

-- 
You received this message because you are subscribed to the Google Groups 
"Django users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-users+unsubscr...@googlegroups.com.
To post to this group, send email to django-users@googlegroups.com.
Visit this group at http://groups.google.com/group/django-users.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-users/004E3AC7-169E-4647-B913-EA6A20EFEF77%40polytechnique.org.
For more options, visit https://groups.google.com/groups/opt_out.

Re: Django Debug Toolbar 1.0 beta released

[Aymeric Augustin]

Hello,

I just released 1.0 final. Enjoy!

-- 
Aymeric.

Le dimanche 15 décembre 2013 14:11:50 UTC+1, Aymeric Augustin a écrit :
>
> Hello,
>
> I'm happy to annonce that we're almost ready to release version 1.0 of the 
> Debug Toolbar! Now we need your help to try the beta:
>
> https://github.com/django-debug-toolbar/django-debug-toolbar/releases/tag/1.0-beta
>
> The documentation is available on Read the Docs — make sure you read the 
> "latest" version as there are many changes since 0.11:
> http://django-debug-toolbar.readthedocs.org/en/latest/
>
> Note that the setup process is different from previous versions:
>
> http://django-debug-toolbar.readthedocs.org/en/latest/installation.html#quick-setup
>
> Please report issues on GitHub:
> https://github.com/django-debug-toolbar/django-debug-toolbar/issues
>
> If no major problems are found, we'll release 1.0 in one week.
>
> Here are the main changes from version 0.9.x and earlier. (Versions 0.10 
> and 0.11 were transitory versions leading to 1.0; they were released to 
> validate some choices before committing to support them for the lifetime of 
> 1.x.)
>
> - Panels are now rendered on demand, solving the "20MB HTML page" problem
> - Panels can be individually disabled from the frontend, in case a panel 
> degrades performance severely on a page
> - Interception of redirects can be toggled from the frontend
> - The handle can be dragged along the right side, in case it hides exactly 
> the part of the page you're working on :-) 
> - Static files are managed with django.contrib.staticfiles, solving a 
> series of URL-related issues
> - The setup process was rewritten, to provide a simplified automatic setup 
> and an optional explicit setup
> - Panels and settings received shorter or better names
> - A stable API for third-party panels is documented
> - The core of the toolbar was simplified drastically and almost all the 
> code was refactored into panels
> - The toolbar was made compatible with all current versions of Django and 
> Python, including Python 3.
> - The test suite was expanded and gained Selenium tests
> - Dozens of bugs were fixed
>
> I hope you'll like it!
>
> -- 
> Aymeric.
>

-- 
You received this message because you are subscribed to the Google Groups 
"Django users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-users+unsubscr...@googlegroups.com.
To post to this group, send email to django-users@googlegroups.com.
Visit this group at http://groups.google.com/group/django-users.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-users/46f6f7b3-5b1f-4824-b949-1523c2c92e5a%40googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

Re: dumpdata --format=yaml, dates, and USE_TZ

[Aymeric Augustin]

It's a bug in PyYAML: https://code.djangoproject.com/ticket/18867

-- 
Aymeric.

-- 
You received this message because you are subscribed to the Google Groups 
"Django users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-users+unsubscr...@googlegroups.com.
To post to this group, send email to django-users@googlegroups.com.
Visit this group at http://groups.google.com/group/django-users.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-users/e04d2594-24f3-4886-8c06-f21f0b2fde5b%40googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.