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