An alternative to using IP address to guess timezone would be to get the browser to supply its currrent time as part of a form. This will not give three letter code but it will allow you to deduce a local browser time difference.
Going via IP address is a hassle to setup and maintain and is unlikely to be quick or elegant. My web host is a few time zones away so even my mono-cultural applications need to address this; the intranet apps are the only ones to escape. Regards A On Jun 19, 2:27 pm, "Diez B. Roggisch" <[EMAIL PROTECTED]> wrote: > On Tuesday 19 June 2007 15:20, Sanjay wrote: > > > Hi All, > > > I am developing a turbogears application, intended to have users from > > different time zones. Some of the reports and transactions are based > > on current time (datetime.now()) and current date (date.today()). > > > I wonder how the application will behave if somebody from India > > browses some report, e.g. "what tasks he is assigned to do today", but > > the server being at US, the date.today() would be quite different. > > > Might be a novice question... > > The server will always produce times in the timezone it is configured to run. > If you want an indian citizen to have his real "now", you need to somehow > find out his timezone and create datetime objects with it yourself. > > To do so, you could try and use IP-based localisation, or you might make it a > configurable option in the users profile. > > But I fear that whatever TG will create as dates - e.g. by > FormEncode-validators - will all be in one timezone. So you need to > post-process that. > > Diez --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "TurboGears" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/turbogears?hl=en -~----------~----~----~----~------~----~------~--~---
