January 21, 2021
Hot Topics:

Building WML Gadgets: World Time Clock

  • By Steve Schafer
  • Send Email »
  • More Articles »


As mentioned in the last few articles, it is possible to add value to a mobile device by creating a small but ultimately useful application. In designing such an application, remember that the user will need to be online to use it, so the application's utility needs to be weighed against the potential cost of use.

Note: Most mobile service plans offer a base amount of online time dedicated to "Web" use. So the user generally isn't paying more for the occasional gadget use.

World Time Application

This article describes how to create another useful small application: a world time clock. This clock tells the time in prominent time zones and areas around the world. If you need to make a call to Sydney, Australia, for example, it would be nice to know if you are in danger of waking someone up, or are calling during the lunch hour.

Our world time clock should accomplish the following:

  • Allow the user to search for a given time zone or area
  • Display the accurate time for the zone(s) found
  • Be easy to use, but complete enough to be useful

More Help from CGI

We could utilize only mobile technologies (WML and WMLScript) to accomplish our goals. However, we'd have to do the following:

  • Find a comprehensive time zone database
  • Parse the database into an array in WMLScript
  • Do time and date calculations to determine the time in various zones from the resulting data

At first, this approach doesn't seem too bad. There are a finite number of time zones worldwide. However, you also have to take daylight saving time into account. For example, central Indiana (which includes Indianapolis) does not observe daylight savings. This means that Indiana, geographically in the Central time zone, seemingly bounces between Central and Eastern time zones. (In reality, central Indiana stays on Eastern Standard Time, and the zones around it shift.)

A comprehensive open source database exists that can be used for this purpose. The database, often referred to as the tz or zoneinfo database, is packaged with most implementation of the GNU C Library, primarily Linux installations. Several tools are available for reading the data from the database, including a Perl module, Time::Timezone (available from CPAN, www.cpan.org).

Note: As with previous articles, teaching Perl is out of the scope of this series. There are numerous sources on the Internet for learning Perl, including the tutorial at http://wdvl.internet.com/Authoring/Languages/Perl/PerlfortheWeb/toc.html.

Starting the Script -- Reading Time Zones and Telling Time

To start the script, we will simply output the time zones and the current time for each. The simple script shown below accomplishes this objective:

Listing: tztest.pl


use Time::ZoneInfo ':all';

my $zones = Time::ZoneInfo->new();

foreach my $zone ($zones->zones) {
  print $zone."\n";

This script simply creates a list of all the available zones and outputs each to the console. Next, we need to know what time it is in each zone. Fortunately, the operating system (Linux, in this case) can do the work for us.

Most Linux applications that need to tell time do so by referencing the environment variable TZ. This variable contains the current time zone for the system. The OS can use this variable to decode its internal time clock into the correct value for the zone. If you change this variable and request the time from an application that uses it, you can easily tell the time in another zone.

With help from the Date::Calc module, we can add the current time zone to our test:

Listing: tztest.pl


use Time::ZoneInfo ':all';
use Date::Calc ':all';

my $zones = Time::ZoneInfo->new();

foreach my $zone ($zones->zones) {
  $ENV{TZ} = $zone;
  ($year,$month,$day,$hour,$min,$sec, $doy,$dow,$dst) =
  print $zone.":";
  print $year."-".$month."-".$day."  ";
  print $hour.":".$min.":".$sec."\n";

Sample tztest.pl output:

. . .
America/New_York: 2002-12-29  23:35:22
America/Detroit: 2002-12-29  23:35:22
America/Louisville: 2002-12-29  23:35:22
America/Kentucky/Monticello: 2002-12-29  23:35:22
America/Indianapolis: 2002-12-29  23:35:22
America/Indiana/Marengo: 2002-12-29 23:35:22
America/Indiana/Knox: 2002-12-29  23:35:22
America/Indiana/Vevay: 2002-12-29  23:35:22
America/Chicago: 2002-12-29  22:35:22
America/Menominee: 2002-12-29  22:35:22
America/North_Dakota/Center: 2002-12-29  22:35:22
America/Denver: 2002-12-29  21:35:22
America/Boise: 2002-12-29  21:35:22
America/Shiprock: 2002-12-29  21:35:22
America/Phoenix: 2002-12-29  21:35:22
America/Los_Angeles: 2002-12-29  20:35:22
America/Anchorage: 2002-12-29  19:35:22
America/Juneau: 2002-12-29  19:35:22
America/Yakutat: 2002-12-29  19:35:22
America/Nome: 2002-12-29  19:35:22
America/Adak: 2002-12-29  18:35:22
. . .

Note that we simply change the TZ environment variable and call the System_Clock method. The variable is only changed within the application space, so the change in time zone doesn't affect the whole system--just our application.

Page 1 of 3

This article was originally published on January 10, 2003

Enterprise Development Update

Don't miss an article. Subscribe to our newsletter below.

Thanks for your registration, follow us on our social networks to keep up-to-date