Monthly Archives: June 2010

Timezone selection for web apps

Web applications have an unusual problem regarding timezones and formatted, user-viewable dates for a few reasons:

  • several timezones are usually involved, and the determination of which should be used isn’t particularly clear
  • date formatting code for even a modest list of locales isn’t available in browsers by default

Timezones Everywhere

Desktop applications have it pretty simple. Their users work on a host, and that host has a configured timezone. Windows and Mac users have convenient access to those settings in their “System Properties” or “Control Panel”. If a desktop application needs to display the date or create a time, it has access to the local host timezone. Usually there’s no question…this is the correct timezone for an application to use. If a user temporarily relocates to a different timezone, the user is responsible for changing that setting in his system settings.

Web applications have potentially several timezones to juggle as they manipulate time:

  • client timezone
  • server timezone
  • event location timezone
  • site timezone
  • user account timezone

The client timezone is the computer’s system timezone — the timezone set within system properties or the control panel. This timezone is controlled on the local desktop or host environment. JavaScript in a browser has indirect access to this host provided timezone, and that timezone is available as the default — and usually the only — timezone available to a browser-confined application.

The server timezone is the timezone of the physical server on which your application runs. In a global, world-wide application, this server timezone is probably the least relevant of all the timezones because a server can be almost anywhere in the world and is most likely not representative of the user majority.

The event location timezone is the timezone of an actual event; it is the physical event’s location. For example, world cup soccer matches are held in South Africa this year. It might be tempting to use the event’s timezone when publishing soccer match times. Unfortunately, if I’m a Brazilian fan trying to determine a game time, the South African timezone and time display may not be useful and may be confusing. Here’s an example from a Google search page that shows game times for a U.S. English-speaking user:


The site timezone is the timezone associated with the web app’s domain or site. Let’s use world cup soccer again. Yahoo has dedicated sports sites for various locales/regions around the globe. For example, is primarily the U.S. site, but it has navigational links to allow a user to go to other regional versions of the experience. If you look at a similar schedule of existing or upcoming games, you’ll notice that Yahoo chooses to display times using the site’s timezone.

One view of upcoming games looks like this on the U.S. English site. Notice that it uses Eastern Daylight Time for the site’s timezone:


A different look from the Brazilian site shows this. Note that the times use the BRT timezone:

Screen shot 2010-06-23 at 1.09.45 PM.png

The point here is simple: you have lots of choices for displaying time and time zones to your users. Making the choice is difficult. Once you’ve determined which zone to use, the technical issues aren’t nearly as hard to solve.

In this specific blog, I’ll not solve the technical aspects of displaying time in the proper time zone and format, but I will leave you with my personal suggestion. In general, I think a web site should use as much information as it has available to customize information and to present it clearly to its users. For times and dates, it makes sense to me to present that information in the timezone and format that the user is accustomed to seeing. If your site knows that I’m a U.S. English speaker, maybe you should at least display times using a U.S. timezone. Of course, some regions have multiple zones, and that becomes a new problem. However, in the case of the U.S, which has multiple zones, a California resident is probably more likely to know that EDT is a 3 hour offset. It is doubtful that most California residents would know immediately that South African time is …. well …. some other offset. You see, the South African timezone just doesn’t help me much if I intend to actually watch or record the event. EDT is at least a bit more familiar.

There you have it…some ideas about timezones and their display. Use what your site knows about users to display information. The more localized in formats, the better in my opinion.

Additional Characters in the Joyo Kanji List


Japanese language students must learn 196 additional Kanji to consider themselves literate. These additional characters will be added to the already daunting 1945 characters that are part of the “Joyo Kanji” list, which brings the total count to 2136. Joyo kanji are the basic, fundamental characters of the language…the minimal set that an adult or post high school person should know.

I remember my college days learning Japanese. I thought I was pretty good to have learned the Joyo kanji in my 4 year career. At this point 4 years would barely be enough for me to choke down the additional requirements.

I think the motivation for adding the characters is interesting. As you might imagine, it is much easier to recognize a written kanji than it is to write it oneself. In this digital age, we have lots of help writing kanji. Input methods make it…dare I say…almost easy to write kanji. And since we read so much more than we typically write, and since input methods simplify text entry, we don’t really have to worry about recalling every stroke of any kanji. The software handles this for us nicely. So, not particularly concerned that students be able to accurately write the new characters, Japan’s Agency for Cultural Affairs has added these characters with the primary hope that students should at least read and recognize them.

You can learn a bit more about the Joyo Kanji:

These characters aren’t exotic!

Recently I had the opportunity to sign up for health benefits with a 3rd party site that manages these things for my employer. Sites that collect data often limit the set of characters that you must use for each field. That’s reasonable for numeric fields, date fields, etc. After all, you don’t want invalid data in a field, and you’d like to help users enter correct data wherever possible.

However, I think it’s unreasonable to limit characters that are legitimately used in a field type. For example, these characters show up all the time within perfectly valid names:

  • HYPHEN –

Come on…in 2010 these are not exotic characters. They exist in all kinds of unimpressive, common names….like O’Conner for example! In the figure below, the data collection form dislikes the apostrophe. Come on, it’s part of my name.

Unfortunately this is all too common. Do you have a problematic name? Share it with me…what name causes you grief in online forms?

Mac OS X and server-ish software

I’ve owned a Macbook Pro before…it wasn’t a great experience, but it was acceptable. It was during a period of my career when my primary job was to communicate with other developers and to evangelize Java. The Macbook worked in that environment.

Now my needs are different, but I find myself using another Macbook Pro. Fine machine, don’t get me wrong…but I have to admit that I’m a bit lost regarding how to update the tools that were preloaded with the OS. For example, I find most of the common tools on this machine:

  • perl
  • php
  • apache http server
  • java

In all cases, these tools exist but are outdated in some way. They have newer versions that have features that I’m interested in, and I want to upgrade.

The question now is simple…what is the best way to find and upgrade these types of developer tools in a Mac OS X environment? Colleagues have mentioned “fink” and “Macports”. Are there other sources of Mac OS X software ports for these common developer tools? Do those sources place the new tools in the same locations used by the old tools, effectively replacing them in the system? Or do they place the new tools in a separate, different location?

I’ll find out the answers to these questions on my own as well, but I’m curious if you have tips and suggestions before I get too far down my own newbie path.