On Wed, 2009-11-25 at 10:52 -0800, Rob Hudson wrote:
> I like the solution proposed on ticket 10587:
> http://code.djangoproject.com/ticket/10587
>
> Basically, it proposes that timezones are handled analogous to how
> Unicode is handled -- that is, everything within Django boundaries is
> treated
On Wed, Nov 25, 2009 at 7:10 PM, jedie wrote:
> On 25 Nov., 00:36, Russell Keith-Magee wrote:
>> Why would it be? A datetime field isn't necessarily stored in UTC. It
>> uses datetime.now() because that will return the same time as
>> settings.TIME_ZONE.
>
> To improve my understanding: What if t
On Tue, Nov 24, 2009 at 3:36 PM, Russell Keith-Magee
wrote:
>
> Time zone handling is definitely something that Django could handle
> better, but simply switching to UTC for certain functions isn't the
> solution.
>
I like the solution proposed on ticket 10587:
http://code.djangoproject.com/ticke
On 25 Nov., 00:36, Russell Keith-Magee wrote:
> Why would it be? A datetime field isn't necessarily stored in UTC. It
> uses datetime.now() because that will return the same time as
> settings.TIME_ZONE.
To improve my understanding: What if the server changed and the time
zone is not the same? IM
On Wed, Nov 25, 2009 at 12:10 AM, jedie wrote:
> DateTimeField "auto_now" and "auto_now_add" used datetime.now(). But
> why this? IMHO it's better to use datetime.utcnow(), isn't it?
Why would it be? A datetime field isn't necessarily stored in UTC. It
uses datetime.now() because that will return
DateTimeField "auto_now" and "auto_now_add" used datetime.now(). But
why this? IMHO it's better to use datetime.utcnow(), isn't it?
Mfg.
Jens Diemer
--
You received this message because you are subscribed to the Google Groups
"Django developers" group.
To post to this group, send email to djan
