This section will go into detail about how each of the following widgets capture and store time (Date, Time, Date-Time). We will discuss which settings affect these widgets and how they can work to your benefit.
Before we discuss how the widgets are affected we need some background information to understand why the widgets behave the way they do. TimeZone information can be changed in two places, on the device and on the server.
*** Date-Time element data is stored as GMT in the database. A conversion takes place from the client to the database, and from the database back to the data views/feeds, including E-mail Report and Post XML. ***
The "Device TimeZone" is what users will see on the device when they collect data. The "Server TimeZone" under Company Info, will alter the way users see the data. The date and time are localized to match the Company Info TimeZone.
The TimeZone on the device is changed under the general device settings, and defines the local device time.
The TimeZone on the server is changed by logging in and selecting the "Company Info" drop-down menu from the "Company" top navigation tab. Changing the TimeZone here will not change the time on the device. For example; if the TimeZone on the device is set to "New York" and the TimeZone on the server is set to "San Francisco", users will see the correct time for "New York" displayed on the device.
Now that we have covered some background information about the different places we can change the TimeZone, let's look at each widget individually and see how they behave when changes are made.
-Company TimeZone is set to "London" on the server.
-Two different users are collecting data, one in New York, the other in San Francisco.
-The time is 1:00 AM on 8/10/10 Eastern Standard Time.
-We assume the time difference between New York and London is 5 hours.
The Date widget can be thought of as a label that captures the date from the device. Based on the example scenario above both users tap the "Today" button to capture the present date.
Each user would capture the date based on their local device time. The user in New York would capture 8/10/2010 as the date, while the user in San Francisco would capture 8/9/2010.
The date captured by both users is not affected by the Company Info TimeZone on the server side. This data is captured straight from the device, and not based on Company Timezone. When looking at the data on the server, each user will have captured a different Date because of the local TimeZone difference.
The Time widget behaves the same way as the Date widget and is controlled by the TimeZone settings on the device. Using the same example scenario, both users capture the current time by tapping the "Now" button. The user collecting data in New York will capture the time as 1:00 AM, while the user collecting data in San Francisco will capture the time as 11:00 PM.
Similar to the Date widget, Time widgets capture data directly from the device. Having the TimeZone set to "London" on the server under Company Info will not affect this data. When looking at the data on the server, each user will have captured a different Time because of the local TimeZone difference.
The "Date-Time" widget is different from the "Date" and "Time" widgets, because the data is based to the TimeZone defined under Company Info on the server.
Both of our users will capture data based on the date and time on the device. However, when the data is sent back to the server, both of the records will be localized to match the date and time in London. So even though the user in New York will capture 1:00 AM 8/10/2010, when we view the record on the server, it will be localized as 6:00 AM 8/10/2010.
The user in San Francisco will capture 11:00 PM 8/9/2010 on the device, but when the record is viewed on the server, it will be localized to display 6:00 AM 8/10/2010.
What this means is that no matter where users are collecting data, it will always be localized to match the TimeZone displayed under Company Info.
The major difference is that data captured using the "Date-Time" widget will be localized based on what the Company TimeZone is. For example, if the company moves and needs to change TimeZone's on the server, all of the data collected using the "Date-Time" widget will be re-localized to match the new Company TimeZone. Data captured using either the "Date" or "Time" widgets will remain unaltered.
Now that we have explained how each of these widgets behave, we will examine when it is appropriate to use each widget.
When a user wants to capture an absolute time value, such as "2:00 PM" and does not care about localization, they should use the Time widget.
When a user wants to capture an absolute date value, such as "8/10/2010" and does not care about localization, they should use the Date widget.
When a user wants to capture a value where the TimeZone is important and they want the data to be localized based on the Company TimeZone, they should use the Date-Time widget.
The Date-Time widget is the only widget with "TimeZone Aware" capabilities and will be localized to coincide with the TimeZone that is set in the Company Info section. It does not matter where any of the users collect data, it will always come back to the server automatically localized to match the Timezone that is set in the Company Info section.