Time Zone Selection

Every TimelineView is governed by a single timezone. The default behavior of the TimelineView is to use the User's timezone.

For example, the user may enter Timezone filter values of November 1, 2013 through November 30, 2013. If the User's Timezone is Central Standard Time, then the buckets for a daily TimelineView would represent:


  • Nov 1, 12:00AM CST to Nov 1, 11:59:59PM CST

  • Nov 2, 12:00AM CST to Nov 2, 11:59:59PM CST

  • etc

The implications of this are critically important. For example, assume there exists a data measure that counts the number of Shipments arriving per day. If you have a Shipment arriving at 12:00AM EST Nov 2, then two different users will actually see that shipment being counted in a different bucket:


  • User in Eastern time will see the value in the Nov 2 bucket

  • User in Central time will see the value in the Nov 1 bucket, since Nov 2 12:00AM EST = Nov 1 11:00PM CST

This bucketization of data may or may not be correct based on the business case. In the scenario above, it probably makes the most sense to use the Site's timezone, that way any user will always see the same bucketization of the data. (This only makes sense if all the data on the page is for the same site. We'll show you how to deal with mixed timezones later.) Assume for now that the Site is one of the filters to the TLV; we can use that filter to look up the proper timezone and apply it to the TLV.


Platform provides an optional TimezoneSql tag in the TLV schema for selecting the governing timezone. (This element should be placed just before the other SqlDef elements in your TLV.) When omitted, it uses the User's timezone. When provided, it expects the SQL to return a single column in a single row containing a value usable by java.util.Timezone. Here, we select the TIME_ZONE_ID column from the SITE which is provided as in filter SITE_ID by the user:

...
<TimezoneSql Name="TZLookup" GroupName="TLVTimezoneSQLs">
select TIME_ZONE_ID from SITE where SYS_SITE_ID = $SITE_ID$
</TimezoneSql>
...


As a convenience, the user's timezone is provided as $USER_TZ$ to the SQL in case you want to fall back on the user timezone. Also, typical context parameters like $MY_ENT_ID$, $MY_ORG_ID$, etc. are available.