Re: timezone.now() when USE_TZ=true

[Anssi Kääriäinen]

On Jun 1, 10:27 am, Artem Andreev <andreev.ar...@gmail.com> wrote:
> Hello!
>
> In django 1.4 with USE_TZ=true timezone.now() returns
> datetime.utcnow().replace(tzinfo=utc).
> Such datetime aware objects are handled properly in forms, templates and
> other places inside django framework.
> But when I prepare datetimes for ajax responses using strftime I always do
> localtime(timezone.now()).
> Same conversion I should do for any requests to external APIs which don't
> know about timezones.
>
> I couldn't find any discussions and arguments what timezone.now() should
> return.
>
> May be it will be more practical/comfortable for django users if
> timezone.now() will return localetime?
> What do you think about this?

The idea is that inside Python all datetimes are handled in time zone
UTC. The rule is simple: you should keep the datetimes in UTC as long
as you can. You should only convert the datetimes to other time zones
if it is required by:
- You need to display the data to users
- You need to pass the data to external systems which can't handle
UTC datetimes
- You need to do calculations which depend on the timezone (the most
common one is "what date is it now in timezone X?".

So, timezone.now() returns the correct value. UTC-datetime is what you
want in Python. There maybe could be a shortcut function for local-
now.

- Anssi

[Aymeric Augustin]

2012/6/1 Artem Andreev <andree...@gmail.com>:

> May be it will be more practical/comfortable for django users if
> timezone.now() will return localetime?
> What do you think about this?

Hi Artem,

In fact this problem isn't limited to timezone.now(): any datetime
returned by the database will be expressed with tzinfo = UTC. All
datetimes have to be converted when they're exchanged with another
system that expects something other than UTC.

In your situation, you are supposed to adapt your serialization
function to convert datetimes according to your needs. Some APIs may
expect UTC, others may expect naive local time, others may expect
local time with a stated offset, etc. So there's no choice (UTC,
default TZ, current TZ) will satisfy everyone.

That's why I chose to stick with the sanest and least controversial
choice: UTC. Arithmetic works without surprises and performance isn't
hindered by conversions.

Best regards,

--
Aymeric.

[Artem Andreev]

Anssi, Aymeric thanks!

I enabled USE_TZ only 3 days ago and missed that any datetime returned by the database is expressed with tzinfo = UTC. Until that moment I though that function localtimezone.now() that will return localtime(timezone.now()) solves most of my problems. Now I want to turn off USE_TZ :) Joking apart but seems as a lot of systems expect datetime naive. Also I have a lot of ajax responses. Thus I should converts a lot of manually, which increases the possibility of error. Maybe this is just my experience.

[Aymeric Augustin]

On 1 juin 2012, at 20:56, Artem Andreev wrote:
> seems as a lot of systems expect datetime naive

Yes, that's unfortunate. All hope is not lost. 10 years ago, lots of systems expected ASCII and choked on UTF-8; some have improved since then.

> I should converts a lot of manually, which increases the possibility of error. Maybe this is just my experience.

You should be able to control this problem with a function or class that handles all you AJAX responses. When you say "AJAX", I suppose you're returning JSON. This function would walk through the datastructure, find datetimes, and convert them to local time, before serializing in JSON.

Best regards,

--
Aymeric.

[Artem Andreev]

суббота, 2 июня 2012 г., 1:05:01 UTC+4 пользователь Aymeric Augustin написал:

On 1 juin 2012, at 20:56, Artem Andreev wrote:
> I should converts a lot of manually, which increases the possibility of error. Maybe this is just my experience.

You should be able to control this problem with a function or class that handles all you AJAX responses. When you say "AJAX", I suppose you're returning JSON. This function would walk through the datastructure, find datetimes, and convert them to local time, before serializing in JSON.

Thanks, Aymeric.

Of course, I can create something like function localize_datetimes and use it in JSONResponseMixin and all places where I send data to external systems.

But such function, JSONResponseMixin, etc should implement all django users who works with AJAX and external systems that expects datetime naive.

Other solution - if database layer and timezone.now() will return datetimes with active timezone. IMHO such solution more friendly to django users.

I understand that I am a little late to this discussion. And such cases can affect not so much django users.

Perhaps it would be better to wait a feedback from other users.