Companies gain productivity from continuous work force

One of the wonderful benefits of any global company is the productivity achieved by having a continuous work force. As one group of employees in the US go home, another set in India begins its day. It’s an oversimplification for sure, but I have no doubt that global companies gain real productivity.

Here’s an example of real productivity. It is now Sunday night on April 17, about 11:35 PM in my local time zone. I’ve just responded to an email that’s been in my INBOX over the weekend. Fortunately, even though it’s late for me, and I’m really, really exhausted, my colleague in India is fresh and perhaps just going for his lunch break on Monday afternoon. He can take my email response and act upon it. The contents of the email provide a helpful tip for fixing a unit test. The end result is that the corporate product — the software in this case — has continuous nurturing, updates, and improvements.

The problem is at the micro level, however. While the larger company product benefits, sometimes individuals that work in that environment burn out. I’m no where near that, but I can see a pattern evolving that could lead to that. You see, for me, the work day never ends. Somewhere in the world, someone is working on a problem that I am also working on. Ideally, the handoff would be a clearly distinguished time. That is, I might get an email in the morning, work on the issue, then respond before my end of day. Then my colleague in India would awake (and I’d be asleep), and then he would continue working.

In reality, however, the actual work day never really ends for some of these people. For example, I stay up late to get a real-time response back. Or I might use an instant messenger tool to get an immediate response from a colleague around the world. This continues for several weeks until finally someone gets ill and has to take a few days extra rest. At the micro level — at the real person level — around-the-clock work is not a good thing. It takes its toll on energy level, family interactions, and even health.

In the end, I still think a company can benefit from a global workforce. However, individuals must be disciplined to let one shift end and another begin without feeling the need to constantly communicate in real time. In a global workforce, asynchronous email is a great thing. I have to remind myself of that regularly. Like now. Time for bed. No more work for me. Good night India.


Determining a visitor’s timezone

We’ve already decided that determining a timezone for a desktop application is easy. It’s too easy, and so let’s not even waste our time there. Instead, let’s think about something more difficult: how do you determine the timezone of a visitor to your website?

If your site authenticates users, you have most of your problem solved. Along with your user’s preference for username, password, and favorite soccer team (if soccer is your web site’s focus), you can encourage users to register their locale and timezone. This really isn’t so much to ask, not if you are going to offer them rich, useful, or entertaining content.

So ask for a timezone preference! When you ask, however, make sure you ask for something more useful than a simple UTC time offset. Knowing that a visitor is in a UTC-8:00 time zone is helpful but not as helpful as knowing that that same visitor is in the Los Angeles/America time zone. The latter option obviously provides more information about the user. Of course, the Los Angeles/America time zone tells your system that a visitor requires a UTC-8 offset, but it also differentiates this user from someone in Canada that may use the same hour:minute offset. It’s more information! More information usually translates into a better user experience, especially if you take care to utilize that information to customize the experience.

It is also possible to get the browser’s default timezone using a bit of JavaScript. Is this the user’s preference? Maybe, maybe not, but it is available. I’ve heard arguments that suggest that this is not the correct timezone to use. However, my opinion is emphatically this: the timezone of the user’s host pc is probably the best thing you have available in the absence of a specific user preference setting. Yes, people move around; yes, a user can visit your site on the west coast one day and then the east coast the next day without changing the pc setting.

var d = new Date();
var tzOffset = d.getTimezoneOffset();

Is this perfect? No, not at all. In fact, this javascript really just provides a minute value offset from GMT and local time. Still, for formatting a time with a correct timezone offset, this is useful.

If you don’t use a user preference setting in your app or a bit of JavaScript to query your visitor’s host timezone, what else do we have? Hmm…that’s an interesting question. What else is available for determining the timezone of a user visiting your site? Well, they do have an IP address. There are public services and databases that attempt to map this for you, but I just don’t know how accurate this is. I suppose I don’t have any specific reason to doubt its viability; it certainly seems possible at some level. But I’ve not actually spoken with anyone that has used this accurately or successfully. If you have, let me know.

Until next time!


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.