views:

1839

answers:

2

(I am new to Python and Google App Engine, please forgive me if my questions seem basic).

I'm having a helluva time trying to manage multiple user timezones in my Google App Engine application.

Here are my constraints:

  1. If a user enters the time on an input, it will be local time (including DST, when appropriate).
  2. If a user does not enter the time, the system must enter it for them in their local time (including DST, when appropriate).
  3. When the date and time are displayed to the user, it must be in their local time (including DST, when appropriate)

I understand that time will be internally stored as UTC with a tzinfo object and that the App Engine will store the Models with UTC time.

I previously thought I had this all worked out by asking the user to specify their time zone in their preferences. Then, I would simply load their preferences and add that tzinfo to any datetime objects in reference to that user.

However, our recent daylight saving time broke it. It turns out that I had not correctly implemented the dst() in my tzinfo objects. As I understand it, I must determine if DST is currently on, and if so, return the correct offset for the tzinfo.

The problem is, I have no idea how to determine if the timezone's daylight time is current or not. Am I missing something obvious?

+6  A: 

If you can, I'd recommend having a look at the python-dateutil package, which has tz objects pre-built for all timezones, including DST offset information. I don't think there's a way to "just know" if DST is on or not without supporting data... it's date driven for most timezones (or, at least, timezones that support DST), and the dates vary according to local custom, politics, and all manner of things.

http://labix.org/python-dateutil

Jarret Hardie
I currently use dateutil for parsing etc. There are two problems with it, 1) it requires a file that I don't have to build the tzinfos and 2) it's determination of Daylight Saving time is based on the Google App Engine time, not the user's time (using a browser).
mawcs
I thought that file shipped with the package... it seemed to be there when I downloaded the distro just now.
Jarret Hardie
Indeed, to calculate current time, or convert a time, it needs the time, DST and timezone of the server/origin TZ to determine the offset against the target TZ... but it is possible to instantiate a specific time (ie: 4pm, as opposed to 'now') in a TZ without reference to the server's clock.
Jarret Hardie
Ah, I see it's a zip... Thanks for pointing that out. I will give that a try and see if it solve my problem.
mawcs
Oh... sorry... yes, I should have been clearer that it's a zip. Glad you found it though... hope it works.
Jarret Hardie
Woohoo! it works! Jarret, you rock!
mawcs
Nice! I'm glad to hear it! Whoever invented DST should be punished slowly, IMHO :-)
Jarret Hardie
A: 

I see some problems here.

If the user enters the time, it enters it in local timezone, but how do you know which one is it? Europe/Vilnius or Europe/Madrid? Or maybe Australia/Melbourne? If you don't know the timezone, the date/time becomes "naive".

The only timezone database which is considered appropriate and accurate (considering the state of constant flux) is Olson timezone db, available for Python as pytz package. It allows for easy converting dates/times between timezones: first you take date/time and timezone from user, localize date/time in user's timezone then take it as utc, ready to save to your database. Display is other way around: get date/time from database, localize in utc, then display as user timezone.

And the last thing: there is no such thing as automatic DST transformation. In the case of ambiguous dates/times you have to know in advance in which timezone the time is entered. That's our human reality.

zgoda
I wonder if you missed the part where I said, "...by asking the user to specify their time zone in their preferences..." So, I know the user's input timezone up-front. I don't have quota space for pytz and the python-dateutil package is much lighter-weight than pytz and provides everthing I need.
mawcs
Well, yes, actually... As for the package size, the complete pytz is 8 files, ~500kB. Not that much.
zgoda