29 Mar 09 Event Calendar: Time Zone Picker and Updates
I ended up creating a time zone picker for the event calendar. I saw the idea on the web somewhere. The problem is that there are nearly 400 common time zones in the database. Since every time zone is named in the format “area/location”, I created an area select and a location select. That broke up the time zones nicely, although some of the areas still have far too many entries to be completely convenient. I wrote a short Python script that parsed the pytz common time zones and generated a Javascript object literal to contain the select menus contents. Here is a screen shot showing it in action:
When you select an area (the left-most) control, the location select fills with the appropriate options. When the form is submitted, some Javascript runs to take the two select values and puts them together and populates a hidden time zone input field with the result. So, in the example above, when the form is submitted, the hidden field receives “US/Pacific”. Likewise, when the form is displayed, the hidden field is parsed and the two select controls are set accordingly. This works pretty well, although I think I could have done a better job of modularizing this code in case I need to use it in another place on the site (such as in a user’s profile). I will definitely do this later.
I’ve decided to tackle recurring events later, as it seems a bit involved, and as I stated, very few events on the calendar need this capability. So with the time zone picker in place, and the corresponding code on the server side (thanks to pytz), I can now accurately add events to the event calendar without losing local time information.
I also sat down finally and converted The Madeira’s website from mod_python to mod_wsgi. This wouldn’t have been possible without the excellent documentation that mod_wsgi has. I feel this will scale better, and it will allow me to more easily run multiple Python web applications side by side. I am anxious to get a Trac issue tracker running as well as a beta version of the new site.
The rest of the weekend was spent working the “to-do” list for the site in preparation for deploying a beta version. I really do need to get an issue tracker going to capture all the ideas and work I need to complete.
18 Mar 09 Event Calendar: Oh yeah, time zones…
Very shortly after I wrote the last blog entry I began having some nagging doubts about time zones. The current PHP version of the calendar is really time zone agnostic. It is assumed that when you see an event for California, for example, that you understand the time for the event is local to the Pacific time zone. I was kind of hoping to dodge this problem, but it seems unavoidable now that I am using Google calendar for the back-end.
The Google calendar has a time zone associated with it that I set when I created it. I am using my own local time zone: Central Standard Time, aka CST, aka GMT-6. Well, currently we are in daylight savings time (ack), so it is actually CDT, or GMT-5. When I initially added events to Google calendar, I naively just added them without providing any time zone information. Being somewhat new to Python, I haven’t totally come to grips with how Python deals with time zones, and I was just hacking with my blinders on. Well, needless to say, this didn’t work well, as Google simply assumed I was providing UTC times. Thus when they were displayed on my Google calendar, they had a nice 5 hour offset. Oops. Okay, to “fix” that, I peeked at django-cal, and noticed it was using a Django utility to provide the required time zone information. Using that technique, I got my events to show up in the correct local time on my Google calendar. Hooray!
But wait, that isn’t the whole story. Users can look at my Google calendar, and choose to copy events to their own Google calendars, which may have different time zones. Therefore, if a user submits an event to my calendar that takes place in California, my current code sets the time zone incorrectly. However this isn’t obvious as the time on my calendar will still be the same as the user entered it. But, if that user chooses to copy the event back to her California-based calendar, the event will suddenly be off by 2 hours. Crap!
So it looks like I do need to come to terms with time zones, and bite the bullet and ask the user what time zone the event is in. I am currently studying how Python handles time zones, and looking at pytz, a nice Python interface to the famous Olson database of timezones. Do I need to build some kind of time zone picker? I’m not finding a lot of those, which makes me wonder. In any event, this is seriously complicating my event calendar. But it is pretty interesting stuff and I hope I can get it right, as I really do want the events on my calendar to reflect accurate local times.
