> 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 -~----------~----~----~----~------~----~------~--~---
