On Feb 21, 12:02 pm, Aymeric Augustin
wrote:
> os.environ['TZ'] controls the ouptut of functions such as
> datetime.fromtimestamp().
>
> If you're running with USE_TZ = True, you should use the UTC versions, e.g.
> datetime.utcfromtimestamp() in your own code. However, you may be relying on
> t
On 21 févr. 2012, at 10:49, Anssi Kääriäinen wrote:
>>> I can't see any point why the time zone for the process
>>> should be something else? What is gained by that? Isn't using Europe/
>>> Helsinki for the process timezone downright dangerous due to daylight
>>> saving times? Am I missing somethi
On Feb 21, 10:57 am, Danny Adair wrote:
> The question was if TIME_ZONE is not UTC then whose "today" should it
> be? And in that case I just find the user's "today" more logical than
> the server's.
My point is that it should always be UTC. When you insert a date into
the database, it will appea
On Tue, Feb 21, 2012 at 21:00, Anssi Kääriäinen wrote:
>[...]
> The real problem is, as said before, that whatever you do, last edited
> date doesn't work in multi-timezone setting. Somebody is going to see
> last edited "tomorrow" or seeing his last edit as "yesterday".
I agree, "last edited" as
On Feb 21, 2:33 am, Danny Adair wrote:
> On Tue, Feb 21, 2012 at 13:17, Yo-Yo Ma wrote:
> > I haven't quite read up on all the UTC-related stuff in Django as of
> > yet (couldn't find much info about it), but I found some of the posts
> > above concerning. It would seem that if a DateTimeField sh
Thanks, Danny. That's really helpful to me, and I appreciate you
taking the time to explain it.
--
You received this message because you are subscribed to the Google Groups
"Django developers" group.
To post to this group, send email to django-developers@googlegroups.com.
To unsubscribe from thi
On Tue, Feb 21, 2012 at 14:17, Yo-Yo Ma wrote:
>[...]
> When using UTC, which, if any, are true:
Not sure what you mean by "using UTC", I assume you mean "USE_TZ = True".
As per first sentence of
https://docs.djangoproject.com/en/dev/topics/i18n/timezones/
"When support for time zones is enabled,
I actually know so little that I was even more confused by my own
question, but I appreciate your reply, Danny. I feel pretty challenged
when I try to understand timezone-related stuff. Is this correct:
When using UTC, which, if any, are true:
A) If I have a view that simply adds a record of a mo
On Tue, Feb 21, 2012 at 13:17, Yo-Yo Ma wrote:
> I haven't quite read up on all the UTC-related stuff in Django as of
> yet (couldn't find much info about it), but I found some of the posts
> above concerning. It would seem that if a DateTimeField should be
> updated with ``timezone.now()``, then
I haven't quite read up on all the UTC-related stuff in Django as of
yet (couldn't find much info about it), but I found some of the posts
above concerning. It would seem that if a DateTimeField should be
updated with ``timezone.now()``, then a DateField should be updated
with ``timezone.now().toda
On Tue, Feb 21, 2012 at 10:48, Anssi Kääriäinen wrote:
>[...]
> Current documentation doesn't help here.
I agree that a "Timezones FAQ" should mention
DateField(auto_now=True), with a reference from there also back to the
FAQ.
Really the complication are the timezones themselves, not the
mechani
On Feb 20, 11:18 pm, Danny Adair wrote:
> On Tue, Feb 21, 2012 at 09:29, Anssi Kääriäinen
> wrote:
> >[...]
> >> This is by design. Timezones don't make sense for date or times, only for
> >> datetimes.
>
> > In [15]: activate('Australia/Sydney')
> > In [16]: localtime(now()).date()
> > Out[16]
On Tue, Feb 21, 2012 at 09:29, Anssi Kääriäinen wrote:
>[...]
>> This is by design. Timezones don't make sense for date or times, only for
>> datetimes.
>
> In [15]: activate('Australia/Sydney')
> In [16]: localtime(now()).date()
> Out[16]: datetime.date(2012, 2, 21)
> In [17]: activate('Europe/H
On Feb 20, 8:57 pm, Aymeric Augustin
wrote:
> On 20 févr. 2012, at 19:52, Yo-Yo Ma wrote:
>
> > On a related note, the new timezone.now() functionality is used for
> > ``DateTimeField.pre_save`` when ``auto_now=True``, but it isn't used
> > for ``DateField.pre_save`` or ``TimeField.pre_save``. Is
On 20 févr. 2012, at 19:52, Yo-Yo Ma wrote:
> On a related note, the new timezone.now() functionality is used for
> ``DateTimeField.pre_save`` when ``auto_now=True``, but it isn't used
> for ``DateField.pre_save`` or ``TimeField.pre_save``. Is this a bug I
> should report, or is there something I'
On a related note, the new timezone.now() functionality is used for
``DateTimeField.pre_save`` when ``auto_now=True``, but it isn't used
for ``DateField.pre_save`` or ``TimeField.pre_save``. Is this a bug I
should report, or is there something I'm missing (I'm pretty
uninformed when it comes to UTC
If you call ``QuerySet.update`` on the following model, you'll get the
results that proceed it:
# models.py
class Person(models.Model):
cool = models.BooleanField(default=False)
updated_on=DateTimeField(auto_now=True)
# django-admin.py shell
>>> from myapp.models import Person
>>>
>>> #
17 matches
Mail list logo
