(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:
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?
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
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.
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With