Today, users often travel with laptops, tablet computers, smartphones, and other computing devices from one time zone to another. Such time zone change may require conversion of meeting times, travel itineraries, and/or other user data stored on the computing devices. For example, a user traveling from New York to Berlin may desire to have his/her appointments displayed in Berlin time when in Berlin. Currently, computing devices use a set of built-in conversion rules to account for such time zone changes. The built-in rules may be pre-installed in operating systems, web browsers, or other applications.
However, authorities may occasionally or even frequently change time keeping rules in their respective countries. For example, Germany may decide to institute (or abolish) daylight saving time for a particular year. As a result, conversions to Berlin time based on the pre-installed built-in rules may be one hour earlier (or late) then actual local time in Berlin. Such discrepancies may cause missed meeting appointments, missed flights, and/or other inconveniences.
The present technology is directed to techniques for dynamically managing time zone conversions on computing devices. For example, one technique can include maintaining a set of current time zone settings on a server and generating a set of time zone rules based thereon. Each of the set of time zone rules can include a time zone identifier, a start date, and a time offset from a standard time beginning from the start date. Upon receiving a request from a client device, the server can transmit the set of time zone rules to the client device.
In accordance with another aspect of the present technology, the client device can convert certain user data based on the set of time zone rules received from the server. For example, the client device can compare a time zone of the user data to a target time zone of the client device. The target time zone may be a user selected time zone, an automatically detected time zone by the client device, or other suitably designated time zones. If the time zones do not match, the client device can convert a time stamp of the user data to the target time zone based on the set of time zone rules, instead of relying on local system time of the client device. As a result, the user data may have the correct time stamp irrespective of the accuracy of the local system time on the client device.
This Summary is provided to introduce a selection of concepts in a simplified form that are further described below in the Detailed Description. This Summary is not intended to identify key features or essential features of the claimed subject matter, nor is it intended to be used to limit the scope of the claimed subject matter.
Various embodiments of systems, devices, components, modules, routines, and processes for dynamically managing time zone conversion are described below. In the following description, example software codes, values, and other specific details are included to provide a thorough understanding of various embodiments of the present technology. A person skilled in the relevant art will also understand that the technology may have additional embodiments. The technology may also be practiced without several of the details of the embodiments described below with reference to
As used herein, the term “time zone sensitive data” generally refers to data whose value may be affected by a time zone change. For example, time zone sensitive data can include an appointment date/time, a task due date, an email reception time, an email send time, a birthdate, and/or other suitable data. Also, as used herein, the term “standard time” generally refers to a time scale based on the rotation of the Earth. Examples of standard time include Coordinated Universal Time (“UTC”), Greenwich Mean Time (“GMT”), Universal Time 0 (“UT0”), Universal Time 1 (“UT1”), Universal Time 1R (“UT1R”), Universal Time 2 (“UT2”), Universal Time 2R (“UT2R”), and/or other suitable time scales.
As discussed above, authorities may occasionally or even frequently change time keeping rules in their respective countries. Such changes may cause local system time in client devices to be incorrect based on pre-installed built-in time zone conversion rules. To remedy such discrepancies, conventional techniques may require downloading an entire set of time zone sensitive data, updates to operating systems, web browsers, and/or other applications on the client devices. Such downloads can occupy limited communication bandwidths and/or storage capacity on the client devices. As discussed in more detail below, the present technology can address at least certain aspects of the foregoing difficulty by maintaining a set of current time zone rules on a server and synchronizes the rules between the server and client devices. As a result, the client devices may correctly convert time zone sensitive data irrespective of the accuracy of the local system time.
The server 102 can be an enterprise server (e.g., an Microsoft® Exchange server), a mail server, a web server, a cloud server, an application server, a catalog server, a communication server, and/or other suitable types of server. As shown in
As shown in
As shown above, the time zone settings 104 can include a location of the registry (i.e., “[HKEY_LOCAL_MACHINE . . . ”]), a display name (i.e., “(UTC+02:00) Beirut”), a daylight savings time field (i.e., “Dlt”), a standard time field (i.e., “Std”), and multiple user interface display settings (i.e., “MUI_Display,” “MUI_Dlt,” and “MUI_Std”). In other embodiments, the registry entry may also include a plurality of entries for dynamic daylight savings time settings (not shown) and/or other suitable entries. In further embodiments, the storage 103 may maintain the time zone settings 104 as database records, as XML files, as text files, and/or as other suitable data records.
The processor 120 can generate the time zone rules 106 based on the time zone settings 104. In one embodiment, the processor 120 can generate the time zone rules 106 each time upon receiving a request from the client device 110 or from other client devices (not shown) for the time zone rules 106. In another embodiment, the processor 120 can generate the time zone rules 106 upon receiving a first request from the client device 110 and store the generated time zone rules 106 in the memory 122 (e.g., cache). Upon receiving subsequent requests, the server 102 may provide the time zone rules 106 stored in the memory 122. In yet another embodiment, the processor 120 can generate the time zone rules 106 periodically (e.g., every hour, day, week, month, year, etc.) and store the generated time zone rules 106 in the memory 122. In further embodiments, the processor 120 can generate the time zone rules 106 upon a startup of the processor 120 or based on other arrangements.
In certain embodiments, the processor 120 can generate the time zone rules 106 by extracting at least one of a time zone identifier, a start date, and a time offset from a standard time beginning from the start date based on the time zone settings 104. For example, one of the time zone rules 106 for the Middle East time zone may be expressed in JavaScript Object Notation (“JSON”) as follows:
As shown above, the example time zone rule 106 includes the time zone identifier (i.e., “TimeZoneId” with a value of “Middle East Standard Time”) and a plurality of time offsets for various start dates. For example, on Jan. 1, 2010, the offset of the Middle East Standard Time is 120 minutes from UTC. On Mar. 27, 2010, the offset becomes 180 minutes from UTC. On Nov. 10, 2010, the offset reverts to 120 minutes from UTC.
In other embodiments, the time zone rules 106 may include the same or different arrangements of the foregoing and/or additional data (not shown). For example, the offsets may be expressed as date spans with a beginning date and an end date. In the example above, the offset between Jan. 1, 2010 and march 27, 2010 may be expressed as follows:
In further embodiments, the storage 103 may maintain the time zone rules 106 in other suitable arrangements as JSON records, comma separated values, as XML files, as text files, and/or as other suitable files. Even though the generated time zone rules 106 are showing in
In certain embodiments, the client device 110 can include a desktop, a laptop, a tablet computer, a smartphone, and/or other suitable types of computing device. In other embodiments, the client device 110 may also include a software service (e.g., Gmail Web service) running on any of the foregoing or other types of computing devices. As shown in
The network interface 112 can include a network adapter, a wireless network interface controller, and/or other suitable hardware/software configured to connect the client device 110 to the server 102 via the network 108 or other suitable networks. The user interface 118 can include a display, a touch screen, a keyboard, a track ball, and/or other suitable types of input/output components configured to accept input from and/or provide output to a user. The data store 143 can include magnetic disk storage media, optical storage media, flash memory drives, and/or other suitable persistent computer readable storage media excluding propagated signals. The data store 143 can be configured to contain records of user data 142 and the time zone rules 106 received from the server 102. The user data 142 may be stored as WebSQL, IndexDB, and/or other suitable types of data records.
As shown in
The synchronizer 114 can be configured to synchronize data between the server 102 and the client device 110. For example, the synchronizer 114 may synchronize emails, calendar events, tasks, contacts, data files, and/or other suitable user data 142 between the server 102 and the client device 110. At least a portion of the user data 142 may be time zone sensitive data with an associated data time zone. For example, an appointment date/time for a meeting in Berlin may have a designated data time zone (e.g., Central European Summer Time). As such, the appointment date/time in Berlin may be viewed as a “wall clock” that should not change even if the time keeping rules change in Germany. Other portions of the user data 142 may not have a wall clock. For example, a time stamp for an incoming email may not have an associated wall clock. Instead, the time stamp may be a reception time of the email. The synchronizer 114 may also synchronize the time zone rules 106 between the server 102 and the client device 110. In certain embodiments, the synchronizer 114 synchronizes the time zone rules 106 every time the client device 110 is connected to the server 102 via the network 108. In other embodiments, the synchronizer 114 may synchronize the time zone rules 106 periodically, on-demand, and/or based on other suitable arrangements. The synchronizer 114 can be implemented based on file synchronization, version control, distributed file systems, mirroring, and/or other suitable techniques.
The converter 116 can be configured to selectively convert time zone sensitive data received at and/or stored on the client device 110 to a target time zone based on the time zone rules 106 received from the server 102. In certain embodiments, a user may designate the target time zone via the user interface 118. In other embodiments, the client device 110 may automatically detect the target time zone based on, for example, an indication from a cellular network, a WIFI network, and/or other suitable sources. In further embodiments, the target time zone may be selected based on other suitable criteria.
In one embodiment, the converter 116 is configured to compare the data time zone of the user data 142 received from the server 102 to the target time zone. If the time zones do not match, the converter 116 is configured to convert the received user data 142 to the target time zone based on the time zone rules 106. The converted user data 142 can then be stored in the data store 143. In other embodiments, the converter 116 may not perform the foregoing comparing and converting operations upon receiving the user data 142; instead, the received user data 142 from the server 102 may be stored in the data store 143 without time zone conversion. In another embodiment, the converter 116 is configured to compare the time zone of any stored user data 142 from the data store 143 to the target time zone. If the time zones do not match, the converter 116 is configured to convert the stored user data 142 to the target time zone based on the time zone rules 106. The converted user data 142 is then provided to the user interface 118 to be output to the user. Components and functions of the converter 116 are described in more detail below with reference to
In operation, the synchronizer 114 of the client device 110 sends a request to the server 102 via the network interface 112 for synchronizing data. In response, the server 102 transmits the user data 142, the time zone rules 106, and/or other suitable data to the client device 110. The received time zone rules 106 are then stored in the data store 143. In one embodiment, the time zone rules 106 in the data store 143 are overwritten each time data is synchronized. In other embodiments, the stored time zone rules 106 may be updated based on version, date, and/or other suitable criteria. Based on the received time zone rules 106, the converter 116 of the client processor 111 may correctly convert time zone sensitive data, as described in more detail below with reference to
Referring to both
Referring to both
At stage 306, the data time zone is compared to the interface time zone. At stage 308, if the time zones match or substantially similar, the retrieved data is provided to the user interface 118 without alteration at stage 310. The user interface 118 then displays the retrieved data to the user. If the time zones do not match, the received data is converted at stage 310. The converted data is then provided to the user interface 118 for outputting to the user at stage 310. In the example above, the interface time zone (i.e., Eastern Daylight Time) does not match the data time zone (i.e., Central European Summer Time). As a result, the retrieved appointment date/time is converted based on the time zone rules 106, as described in more detail below with reference to
At stage 406, if the input time is not in UTC offset, the process 210 includes converting the input time to UTC offset based on the time zone rules 106 (
If the input time is already in UTC offset, the process proceeds to stage 408 for determining if the output time is expressed in UTC offset. At stage 410, if the output time is not expressed in UTC offset, the output time is converted to UTC offset based on the time zone rules 106 at stage 411, generally similar to converting the input time at stage 407; otherwise, the process proceeds to stage 412 for calculating a difference between the UTC offsets (ΔUTC) of the input time (UTCINPUT) and the output time (UTCOUTPUT) as follows:
ΔUTC=UTCOUTPUT−UTCINPUT
For example, if the input time is Eastern Daylight Time with a UTC offset of −4, and the output time is Central European Summer Time with a UTC offset of +2, the UTC difference between the input time and output time is 6.
At stage 414, the process 210 includes adjusting the input time (Input_Time) with the calculated difference between the UTC offsets to obtain the output time (Output_Time) as follows:
Output_Time=Input_Time+ΔUTC
Thus, in the example above, the output time of Central European Summer Time equals to the input time of Eastern Daylight Time plus 6 hours.
Specific embodiments of the technology have been described above for purposes of illustration. However, various modifications may be made without deviating from the foregoing disclosure. In addition, many of the elements of one embodiment may be combined with other embodiments in addition to or in lieu of the elements of the other embodiments. Accordingly, the technology is not limited except as by the appended claims.