Browse Prior Art Database

Automatic Timezone Detection for a Wireless Handheld Device

IP.com Disclosure Number: IPCOM000130461D
Publication Date: 2005-Oct-31
Document File: 1 page(s) / 26K

Publishing Venue

The IP.com Prior Art Database

Abstract

A wireless handheld device needs to know the time in UTC, as well as the time zone at its current location. This is so that meetings in different timezones can be scheduled properly. This is also a Java requirement. Setting the timezone is already an improvement over setting the device time after the user lands from an airplane, as the user just has to know the local timezone and set that; the device is already synced to the network time. It would be an improvement if the timezone was automatically set. However, the timezone information available from most cell networks does not include daylight savings information, simply the current offset from UTC; this is insufficient. Two approaches could be taken. (1) Phones are starting to use GPS. The handheld could use this information along with a map to determine which timezone it is in. To save space on the device, a partial map could be downloaded based on the approximate location. To help ease privacy concerns, coordinates could be rounded to 1000km radius. (2) The wireless hanheld could ask for a timezone based on the nearest cell tower. A server would have a map of all cell towers, and this could be determined by either getting a list or empiracally, by having a GPS-enabled device report location and strength of new towers; the location would be centered in the coverage area. A device could help ensure privacy by making requests for multiple towers from the server; only the device would know which one would be the real one. Also, a cache would be used so that the device would know the location of the most recent towers (for example, those along a user’s commute). This would both ease server traffic and help keep the device location private. In both techniques, the device would handle boundary cases by the "lazy" approach. If the device is determined to be near the boundary of a timezone, it will keep it the same as the current setting. There would also be a manual override in case it doesn't work. Some cell networks have the local time and offset available for each tower, but this does not provide the handheld sufficient information.

This text was extracted from a Microsoft Word document.
This is the abbreviated version, containing approximately 66% of the total text.

Automatic Time zone Detection

Automatic Time zone Detection for a Wireless Handheld Device

Disclosed Anonymously

A wireless handheld device requires needs to know the time in UTC, as well as the time zone at its current location. This is so that meetings in different time zones can be scheduled properly. This is also, as well as a Java requirement. It Setting the time zone is already an improvement over setting the device time after the user lands from an airplane, as the user just has to know the local time zone and set that; the device is already synced to the network time. It would be an improvement if the time zone was automatically set.

However, the time zone information available from most cell networks does not include daylight savings information, simply the current offset from UTC; this is insufficient.

Two approaches could be taken.

(1) Phones are starting to use GPS. The handheld could use this information along with a map to determine which time zone it is in. To save space on the device, a partial map could be downloaded based on the approximate location. To help ease privacy concerns, coordinates could be rounded to 1000km radius.

(2) The wireless handheld could ask for a time zone based on the nearest cell tower. A server would have a map of all cell towers, and this could be determined by either getting a list or empirically, by having a GPS - enabled device report location and strength of new towers; the location would be centered in the coverage area. A dev...