суббота, 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 proble
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
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
of
2012/6/1 Artem Andreev :
> 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
On Jun 1, 10:27 am, Artem Andreev 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
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
