Thanks for the input. I have a couple questions. Both of you talk about saving the date/time in UTC format. What is the default when using a django DateTimeField? Does it not save it in UTC? If it is not saving it in UTC, what is it saving it in? I thought that one of the things the DateTimeField did for you was convert your input (whether form a user typed input or from a server call to datetime.datetime.now ()) into some sort of internal representation (UTC?). I thought that when I was using the date filter, that it was simply converting that internal representation into my specificied text format. Am I confused here?
I thought about putting the timezone in the profile but that does have the disadvantage that if the user travels, they would have to update their profile to get dates displayed in whatever location they are at. I really don't like that since the people that will be using my app are management, and they often travel (and probably won't want to modify their profile all the time). One thing I thought about is trying to save the timezone info in the session. It seems like there should be a way to set a session variable at login time that reflects the current time zone and then have template tags that access that variable and generate the correct format based on the session variable. Is this a viable option? Since this is an internal site within a company, it is ok for me to require my users to have javascript on. Tim - i assume that with respect to your comment about javascript you are suggesting that identify the timezone via client javascript code and send it with every request? I thought I had read there was something going on in this area, possibly for django 1.2 but I can't remember what I saw about that ... Would be curious if there is anything planned for develpment in this area as I could possibly wait a few months to implement this if there was going to be some additional support coming on the django side. Margie On Sep 3, 3:02 pm, Tim Chase <django.us...@tim.thechases.com> wrote: > > I've created a django app and I soon am going to have users that are > > in multiple timezones. My app is a task management system and it is > > important for users to see dates and times with respect to their own > > time zone. IE, if here in California I create a task at 3PM on Sept > > 3, I want someone in India to see it as being created at 1AM on Sept > > 4. Optimally, if that India employee travels to the US and looks at > > the task creation date, they should see 3PM on Sept 3. Is there a > > "best" way to handle this? Things that come to mind are: > > > 1. Create a deployment for each of my time zones where TIME_ZONE and > > DATE_FORMAT are set appropriately for the time zone associated with > > the deployment. This seems painful ... > > agreed...yuck! > > > 2. Have a single deployment and whenever I display dates, use some > > sort of tag that can figure out how to display the date correctly > > based on the user's time zone > > Best that I've found. It's best to store everything in the > database as UTC and then adjust the display for whatever the > relative timezone is. > > > 3. I see there is a reusable app called django-timezones. There is > > not much doc with it, but I'm guessing this is targeted at what I am > > trying to do. > > Not familiar with this one. > > The catch is that HTTP doesn't require the requester to send > their timezone information in the request. So you either have to > store the user's TZ in their user profile information, or you > have to use some client-side JavaScript to get the local TZ. > Both have problems -- If the client has JavaScript turned off (I > tend to fly with NoScript, only white-listing those sites I care > about to be able to run JS) you don't get this information back > from them. On the other side, if your customers travel from TZ > to TZ, they will have to update their profile each time they > move. Neither is a horrible solution, just with their own set of > hiccups. The two solutions can be combined to keep an "expected > TZ" in the user profile, but then take advantage of JS when > available to sniff the local PC's time-zone to override. > > Python's stock TZ handling is a little weak last I experimented > with it, expecting a single TZ for the entire running instance. > There's a library at pytz.sf.net that simplifies a lot of the TZ > pain I've experienced with Python's native datetime libraries. > It also gives good examples and cautions on things that can screw > you up (such as notifications set during a DST rollback time-slot). > > Hope this helps, > > -tim --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Django users" group. To post to this group, send email to django-users@googlegroups.com To unsubscribe from this group, send email to django-users+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/django-users?hl=en -~----------~----~----~----~------~----~------~--~---
