On Fri, Jul 4, 2014 at 12:01 AM, Mike Dewhirst <mi...@dewhirst.com.au> wrote:
> On 3/07/2014 11:57 PM, Jerry Wu wrote:
>>
>> Mike,
>>
>> Sorry for the late reply.
>>
>> Your explanation about "time is constant" makes sense to me. But I still
>> didn't know what to do with time setting following the tutorial.
>
>
> One day I'll do some experiments and *really* understand how it works.
>
> My variables are:
>
> TIME_ZONE = 'Australia/Melbourne'
>
> - time stored in the database eg., "2014-06-30 22:46:29.037+10" which in
> June is AEST - Australian Eastern Standard Time or in March "2014-03-05
> 13:48:15.164+11" is daylight saving time.
>
> - USE_TZ = True

With USE_TZ=True, TIME_ZONE only controls the display of datetimes.
Django should be storing all the database values as UTC, and
converting them to TZ-aware when extracting from the database.

>
> When I find the courage I will try setting TIME_ZONE = 'UTC' and see how
> times are displayed. New ones and existing ones! Maybe I'll do it around the
> next changeover to daylight saving in Melbourne.
>

You probably don't want that, most users don't understand UTC. Always
store in UTC, but display in a human timezone.

Another thing you can do is to allow users to select their timezone
and persist it on their user/profile. You can then use a bit of
middleware to activate that timezone, or if not specified, revert back
to the one specified in settings. In code:

  from django.utils import timezone
  from django.conf import settings

  class TimeZoneMiddleware(object):
      """
      This middleware activates a user's timezone, so that all dates
we give them
      are localised correctly.
      """
      def process_request(self, request):
          if request.user.is_authenticated():
              if user.timezone:
                  try:
                      timezone.activate(profile.timezone)
                      return
                  except:
                      pass
          timezone.activate(settings.TIME_ZONE)

Dates in the database would all be stored in UTC, and converted in to
whatever timezone the end user wishes to use.

Unfortunately, you can't easily determine timezone from HTTP headers,
but for bonus points, you can *request* it from the browser with
javascript and append that data to a form to allow you to provide a
"best guess".

I say "request", because you don't get back a useful timezone like
"Europe/Valencia", you will get "+0200", which is almost impossible to
map to a specific timezone. There are many timezones that have offset
"+0200" at certain points in the year...

Cheers

Tom

-- 
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/CAFHbX1K29Wz3wzoSinh%3Dd0fs3L__Vya65PANQUCkDidTcjWaMA%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Reply via email to