We've been busy ballooning the past few days.

It's been a great adventure, one my family (including parents from out of town) has been joining in on. I'm especially indebted to my father-in-law, who's helped me figure out and even make very significant improvements to the balloon kit.

The images are starting to turn out a little better each flight. I started by lofting my Palm Prē 2 into the sky.

I found both a decent timelapse app and GPS logger for it, and it's an option for smaller helium fills due to its low weight. Unfortunately, most apps for this ill-fated smartphone platform are kind of half-baked, as I found when my phone ran out of battery halfway through the flight. The photos up to that point were fine, but the tracklog seems to have been stored in volatile memory only. Little bugs that could be worked around if the phone's fuzzy little camera sensor is adequate for the scenery.

But it turns out this balloon can heft my DSLR and GPS unit pretty handily. Bigger sensor, better glass, and more reliable location logger!

It was too windy, but we managed to get both a low-altitude test flight and a short, nerve-wracking full-string-length cruise in today:

One of the wind's few benefits is the occasional oblique shot — sometimes the camera momentarily defies gravity and gets whipped towards the horizon. Kind of scary to watch helplessly from below, and usually just results in blurred images, but now and then there's an interesting landscape photograph or two that winds up coming back down.

This is just the tip of the iceberg. Our cameras have taken many thousands of shots in the last three days, and at least 0.8% of them seem to have turned out!

"You know, what they think of you is so fantastic, it's impossible to live up to it. You have no responsibility to live up to it!"

Feynman then "went on to work out equations of wobbles" and it did work out.

I'm struggling with no such renown as Feynman, but the world I live in is still rather intimidating.

As analysts ooh and ahh over resolutions and stock buybacks, as the others bring their latest data centers online, and while so-and-so's multimillion dollar attempt to compete with really-is-great's dominant market share makes the news again — it's impossible to live up to it.

So who cares? My career has netted me an approximate financial worth of negative one house…plus a canister of helium!

This wannabe balloon experiment is ugly, it leaks badly, it's needed rescue from the trash once already. No honorary doctorate here. We're having fun:

Spring is here, and with it the wind and my balloon mapping kit!

Probably not the best combo, but dealing with a bit of gusty weather is just one of many things I'll need to learn more about.

I'd long been interested in messing about with something like Kite Aerial Photography to gather public domain orthoimagery. I never quite could believe that a kite would be very convenient for the task though. A big balloon seemed like a better idea, but I wasn't really sure exactly if or how to best accomplish that.

I also have a tendency to collect tools and instruments and spare parts for all sort of intended hobbies, but then they always end up on the back burner. Sitting at my desk or on the couch working on the big "make software better" project is about the only hobby that's been truly habit-forming, so I've mostly learned to avoid "investing" in gadget acquisition syndrome elsewhere. So long as my laptop stays running, I've got all the workbench I actually use. At least…until the kids are old enough to appreciate other hobbies — I've been telling myself to leverage procrastination talent against my microeconomic weakness.

Well two-and-a-half years old is enough to appreciate a big colorful helium balloon, eh? I jumped on the recent "balloon kit" Kickstarter campaign to kickstart a hobby that will require spending sunny Saturdays outside in the fresh air.

I'm still not entirely sure how to "accomplish" balloon mapping, but I've got a basic start on rigging up a camera and have already started pestering the local industrial gas supplier with newbish questions concerning just how I might fill our first airship with helium.

More details as this story develops!

I rode the train in and the bus back, visiting Portland from 10am on Tuesday to 10am Thursday. The weeks before had been busy too: I didn't even get a chance to join the local Tri-Cities co-working group, being heads down in client work and conference calls. Taking public transportation down the river to a very public town was a good reminder of how community matters — both the tech community and the wide world it should serve.

I was struck by how lovely life can be in a town like Portland — warm coffee shops everywhere, so much fine food and drink in every district, and such useful book and tech and music shops scattered all over, all bustling with interesting and amiable people. And how empty a city can still be — the streets are littered with people who have so blantantly lost or tossed every benefit of society except the worthlessness of its loose change.

So I'm grateful to the many people who helped Portland feel not-too-far from home during my time there:

• Rafa from Grafa Geographic Design, Tim and Ryan at Ecotrust, and Justin with Mapbox were all willing to share lunch and "geo" shop talk with a random stranger from out of town.
• The crew sent by Couchbase gave me a warm welcome to their conference tour, and even let me share some of the things I've been working on lately. It was great to meet some other new Couch and mapping enthusiasts, as well as catch up with what Chris and Tyler and Mikeal are doing these days.
• Big thanks to Ben who opened his home (and vintage electronics closet) and Liz whose promising upstart PDX vintage furniture rental company more-or-less sponsored my lodging (and whose husband I stole for not one but two late evenings of epic retro-nerdish conversation!)

Portland's a great place to get offline but stay connected. Though it's good to be back home, I was blessed to visit again.

Time zones pose an occasional software localization challenge. Assuming your software needs to include this as a configurable setting (more on that below), what's the best way to help a user choose a time zone?

The problem is, there are a lot of time zones. A lot of time zones, most without a naturally elegant identity or universally understood name. Time zones were designed be mostly unthought-of: invented so most people wouldn't have to worry about the effect of longitude on time. Within a time zone's geopolitical boundary, there's little need to think or talk about time zones.

As we'll soon see, timezones are very closely tied to location. People may not know the official name or relative offset or exact boundaries of a particular time zone, but they understand that there is one for any particular place.

Collected examples

To see how a user might expect us to solve this interaction problem, I've gathered a variety of "time zone chooser" examples.

Original Mac — circa 1984

Screenshot via http://macfloppy.net/post/18502052008/susan-kare-designed-the-original-macintosh-control:

This is the Control Panel in the original Macintosh operating system. Note how the user sets the time zone: they don't! A personal computer was more of an island back then; a user set "the" time (their time) and that was that.

Windows 3.1 — circa 1992

For Windows 3.1 applications — remember Netscape Navigator 2.0? — a user would set their timezone configuration via a variable in AUTOEXEC.BAT:

SET TZ=aaahhbbb

For interfaces of the "Application Programming" sort, this general approach is still reasonable. Identifiers referencing rules in the Olson database are preferable to the ambiguous local three letter abbreviations and manually-configured offset values needed here.

Windows NT 3.1 — circa 1993

Screenshot via http://www.guidebookgallery.org/screenshots/winnt31:

While I haven't been able to find a screenshot of this dropdown when expanded, from the looks of things it was sorted by GMT offset (see how there's multiple cities listed in the chosen option?).

Newton OS — circa 1993

Screenshot via http://cs.gmu.edu/~sean/stuff/n800/:

The Newton — a PDA that goes wherever people need to communicate — needed to know about timezones. Already we see a map, and an interface based on locations (major cities) rather than the underlying timezones. Since it's somewhat natural to associate time zones with a list of "nearby" major cities, why not use a map to narrow down that list? Tapping the map pulls up a short list of cities near the stylus.

Windows 9x — circa 1995

Screenshot (s) via http://www.petri.co.il/summer_clock_in_israel_for_2006.htm:

These screenshots confirm my theory of how Windows NT's dropdown worked. There is a map, presumably clickable, but it doesn't actually seem to show the selected timezone. Apparently, there's a reason for that.

Mac OS 9 — circa 1999

Screenshot via http://www.guidebookgallery.org/screenshots/macos90:

By Mac OS 9 we again see a list of cities as the interface to the underlying time zone database. The key takeaway is that a user is only expected to know and find a nearby major city in their timezone — there may be more than one city listed per timezone. This reduces the geopolitical knowledge (and guesswork) necessary to find a suitable setting. Just because I share the same time zone rules as Los Angeles doesn't mean it would come to mind as representative of my locale.

Windows CE — circa 2000

Screenshot via http://h20000.www2.hp.com/bizsupport/TechSupport/Document.jsp?lang=en&cc=us&taskId=115&prodSeriesId=322914&prodTypeId=215348&objectID=c00009393:

Windows CE provided a similar dropdown interface as Microsoft's early desktop interfaces (although certain cities were grouped differently). Note the easy affordance made for switching to a temporary timezone while traveling.

Garmin eTrex/Foretrex — circa 2004

Screenshot via http://www8.garmin.com/manuals/Foretrex201_OwnersManual.pdf, p.44:

An "embedded operating system" for an older device with limited screen space, limited processing power, and limited input surface has a limited solution to the problem: a listing of perhaps two dozen or so world cities (…Samoa, Sydney, Tehran, Tokyo…) followed by the named US time zones. There's also an "Other" option enabling the user to set a custom ±hour/minute offset from UTC.

Note generally that trying to tackle the "time zone" problem with only this last option (forcing the user to manually specify their local time offset) would be broken in at least two ways: it expects the user to know this offset which is usually not the case, and it requires many users to manually change the setting twice a year. (It's broken in three ways if you assume that every time zone is offset from the meridian by whole hour values. Only most, not all, are.)

Web 2.0 — circa 2005

Screenshot of http://www.fogcreek.com/fogbugz/:

Here's an example of a web app making use of an offset-sorted dropdown in the Microsoft style.

Mac OS X Leopard — circa 2007

Screenshot via http://rubenerd.com/p2370-2/:

Mac OS X also let the user select their approximate location via a world map, as we saw early on in the Newton OS. Again, the advantage is: rather than having to think of a major city to search for, the interface shows the options near me — I just have to pick the one I feel is most appropriate of the three or four nearby options.

Garmin nüvi — circa 2007

Screenshot via http://www.gpsmagazine.com/2007/06/garmin_nuvi_250w_review.php?page=7

To be honest, I'm not sure what happens when you press the time zone button. The manuals for many nüvi models say "select a time zone or nearby city from the list", so I think it's safe to assume that this updated hardware still relies on the same limited interface as Garmin's older outdoor GPS units above.

World Wide Web — circa 2009

Screenshot via http://dribbble.com/shots/89371-Me-com-Time-Zone-Picker:

Web apps can show maps too. Here's one (kind of rough perhaps? I'm not sure what's going on with the two different highlights…) from one of Apple's ill-fated Me.com web apps.

Garmin nüvi — circa 2011

Screenshot via http://www.pocketgpsworld.com/Garmin-nuvi-2360-reviewed-37558.php:

GPS receivers know the exact time in UTC and the users' very precise location — the device can use this information to simply set the local time automatically. Many cell phones offer a similar user experience — the phone simply displays the local time of the (nearby) tower it is currently connected to.

America-Wide Web — circa 2010

Sometimes you're only localizing for a limited geographic area. In this case, a web app was built for a service only offered in the United States. It was possible to list common names for the small handful of time zones the app needed to support.

Mac OS X Lion — circa 2012

Recent versions of OS X compare the signal strengths of WiFi routers in range to a database of wireless base station locations to get a fairly precise location fix. Like the nüvi example above, this allows a fully automatic time zone setting. If necessary, the user can still override the setting as in previous versions, by clicking the map or typing the name of a nearby city. In fact, since the preference pane now uses an Internet API to look up the city, it offers a fairly comprehensive list including even some smaller cities.

This interface offers a great deal of flexibility, all centered around the helpful perspective of time zone ("local time") being strongly related to location.

General and perhaps Timely advice

Of course, the best interface is no interface. In a few cases — be careful to make sure yours is really one of them — you can ignore time zones altogether and just deal with local times. In many other cases, you can rely on time and calendar–handling facilities built in to your software's underlying platform. If the user's operating system is already configured to display their local time, it's best to use those APIs whenever possible. Store precise moments of time in a timezone-neutral format like Unix timestamps or alongside their original offset as possible with ISO 8601/RFC 3339 time strings, and convert to local time only when displayed. This often works for web apps, too; you can set a JavaScript Date object using a UTC timestamp and get the calendar values back in the user's local time.

Aside: As a general rule you should never, never attempt to handle applying the chosen time zone information yourself. (You shouldn't be implementing any calendar-based calculations yourself, for that matter.) If you would have to change your code or its configuration to handle a local legislative change to any sort of calendar or timekeeping system — and your work isn't part of a major operating system's platform — you're most likely doing it wrong.

Summary

There may occasionally be times (usually when a shared machine needs to interpret or localize times on behalf of a remote user) that your application must let the user configure a time zone.

If you need to stick with a simple dropdown, grouping regions with shared GMT offsets and DST rules and then ordering by the base offset (basically: longitude) can work. Many examples above do this. (However, avoid simply presenting the user with a list of every time zone in your platform's database. Even if you've managed to filter out the historical ones!)

If you can provide one, a clickable map is better. Include alongside a small database of major cities, or reference a more complete set of populated place names. Try to familiarize yourself with the nuances of the best interface examples above — situations where the user clicks near more than one time zone, other cases where the user would prefer to fine-tune the choice of city, and perhaps other aspects I've missed. Accessibility should also be a concern — how will the user choose a time zone if they aren't very good at seeing or clicking?

And finally, if you just want to convert between Every Time Zone, well…follow that link. Or if you like screenshots of old operating systems, you'll love the GUIdebook website.

Oh, and of course I'd love to hear about other unique and interesting solutions to this "time zone picking" problem if you have some!