On Sat, Jan 21, 2017 at 9:40 AM, Bernd Wechner <bernd.wech...@gmail.com> wrote: > I have a model with this field: > > date_time = models.DateTimeField(default=timezone.now) > > if I look at the generic create form, it inializes the date_time field with > now in UTC, not in local time. > > Now I appreciate there are two things at play here: > > the desired UX is to see now in my time zone. > Django, running on the server has no idea what my time zone is. > > Now I can think my way through this and find some solutions, not short of > imagination here. But as I work on nutting one out, I am struck, as ever, > with the notion that 1. is surely a ubiquitous use case ... namely I cannot > seriously be the first person to have this desire or tackle this problem and > is there not a stock standard approach in Django to doing this? > > As I read it I can find the time zone in Javascript at the client side: > > This works fine for example: > > var tz_name = jstz.determine().name(); > var tz_offset = new Date().getTimezoneOffset()/60; > > giving me pleasing results (though I appreciate, before anyone points it > out, that pleasing results are by no means guaranteed as it as it is > premised on the correct TZ configuration of the client computer among other > things, but the application in mind does not REQUIRE time accuracy (am just > logging events that happened at a given time and timezone errors are of no > practical data integrity or security concerns for a few good reasons) . > > And I can submit these in hidden fields too. > > But the obvious solution, which I find a tad kludgy alas is at the client > side in JS to find the date_time input field, and adjust it's value from UTC > to local time. Right now it's presenting as UTC. > > Even if I could find a way to ask Django to use a different timezone > (tmiezone.activate) it won't kow what Timezone until it's heard from the > client. And it's not in HTTP headers alas, though someone thinks it should > be: > > http://blogs.windwardreports.com/davidt/2010/04/can-we-please-get-a-time-zone-in-the-http-request-header.html > > On submission of course as I can submit the TZ info in hidden fields it > should be easy to convert the submission back to UTC for saving into the > database. > > Still, I wonder openly, is this not long solved, more elegantly? > > Regards, > > Bernd. >
I think you're worrying about the wrong thing here. "Now" is always the same moment everywhere, it does not matter what timezone is currently active when it is recorded, only what timezone is active when it is displayed. As long as you have USE_TZ=True, all your datetimes will be stored in the database in UTC. So, the important thing is setting the appropriate current timezone. As you've discovered, you can perhaps discern the timezone using javascript. We have a snippet of javascript that determines TZ and populates a hidden field in the login form with the browser determined TZ. At login, this extra parameter is pulled out if available, and compared to the setting on the users profile. If the users profile has no current TZ setting, we update their profile with the determined settings. If the user has manually specified a timezone, we don't update it or overwrite it. Finally, we have a small piece of middleware that changes the active timezone to that indicated on the user's profile, orto the server time zone if nothing is indicated or the user is not logged in. Sadly, this isn't code I can share, but we are talking around 40 LOC total. 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 https://groups.google.com/group/django-users. To view this discussion on the web visit https://groups.google.com/d/msgid/django-users/CAFHbX1JbiLgVddenqv3K_fPLXAyXe30S-Yb2%2BZoDrq%3DdOAvPgg%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
