Working with Dates in Viewpoint Javascript

The best minds from Teradata, our partners, and customers blog about whatever takes their fancy.
Teradata Employee

The Viewpoint Portal allows the user to configure their Viewpoint User Profile to display dates in the correct format for any locale and any timezone that is desired. This user profile information is stored on the Viewpoint Server so that all dates can be formatted appropriately either on the server side or on the client side.

The Problems

Different locales have different rules for displaying dates and times. In some locales, the month comes before the day of the month and in others it does not. Some locales use the semicolon to separate hours from minutes, while other locales use a different separator. Some locales use a 24-hour clock and some use the AM/PM designator instead. Daylight Savings Time provides additional problems. Because Daylight Savings Time occurs at different times for different timezones, simply taking the difference in timezone offsets will not work. In the United States, participating states must change at 2AM local time, but not all states participate. In Europe, most countries change at the same UTC (GMT) time, even though the countries are in 3 different timezones. Another example is that San Diego and Tijuana have the same timezone offset from UTC, but change their clocks at different calendar dates. The Javascript Date Object can deal with dates in only two contexts, either in UTC or in the browser's local timezone. The Javascript Date object has no access to information about other timezones.

The Implemented Solution

The Java Date Object has knowledge about all timezones and most and Daylight Savings Time change rules. By obtaining the date of the previous and next timezone changes from the server, the presentation engine can determine the timezone offset of the date that it is working with and display it appropriately. The getUserTimeZone JSP tag provides this information to the client via the timeZoneChanges variable.

taglib prefix=uri=""

Information provided by the Server

Date.prototype.tzData = [ // Central
{ stamp:1225609200000, tz:360 }, // Nov 2, 2008 (future)
{ stamp:1205049600000, tz:300 }, // March 9, 2008 (current)
{ stamp:1194159600000, tz:360 }, // Nov 4, 2007 (prev)
{ stamp:1173600000000, tz:300 } // March 11, 2007 (year ago)

Why not use the Server for All Date Conversions?

The portlet's presentation engine may need to perform transformations on dates other than those explicitly contained in the data. For example, while we could go back to the server for each interpolated date that we wish to show on a chart axis (every 2nd day, for example), doing so would not be an efficient solution to the problem. The portlet's presentation engine might wish to zoom in on data and should be able to do so without going back to the server. As an additional benefit, off-loading the date translation work from the server to the client helps to distribute the workload away from the server.

Date Object Extensions

These functions are analogous to the corresponding Javascript get/set Date functions except that they act with the knowledge of the user's profile. This means that they have knowlege of the format and the necessary timezone corrections when adding or subracting time.


Sets the local year (and optionally month and day of the month).


Sets the local month (0-11, and optionally day of the month).


Sets the local day of the month.


Sets the local hour field (and optionally minutes, seconds, and milliseconds fields)


Sets the local minutes field (and optionally seconds and milliseconds fields)


Sets the local seconds field (and optionally the milliseconds field)


Sets the local millisecond field


Returns the local full year.


Returns the local month (0-11)


Returns the local day of the month.


Returns the local day of the week.


Returns the local hour field.


Returns the local minutes field.


Returns the local seconds field.


Returns the local milliseconds field.


The Date.format extension provides a standardized way to display a large number of date formats. Simply specify which fields to display and format() will display them in the appropriate order and with the correct separators for the locale.

"Ymdhms" = full year, month, day, hours, minutes, seconds

"Ymdhm" = full year, month, day, hours, minutes

"Ymdh" = full year, month, day, hours

"Ymd" = full year, month, day

"ymdhms" = year, month, day, hours, minutes, seconds

"ymdhm" = year, month, day, hours, minutes

"ymdh" = year, month, day, hours

"ymd" = year, month, day

"isoymd" = ISO full year-month-day

"my" = month, year

"mdhms" = month, day, hours, minutes, seconds

"mdhm" = month, day, hours, minutes

"mdh" = month, day, hours

"md" = month, day

"d" = day

"hmS" = hours, minutes, seconds, milliseconds

"hms" = hours, minutes, seconds

"hm" = hours, minutes

"hm_noampm" = hours, minutes

"h" = hours, am/pm

"wmdy" = long month, long day, year

"Month" = long month, eg. March

"month" = short month, eg. Mar

"Day" = long day of the week, eg. Sunday

"day" = short day of the week, eg. Sun

"Date" = full year, month, day (same as "Ymd")

"date" = year, month, day (same as "ymd")

"time" = hours, minutes, seconds (same as "hms")

"Time" = hours, minutes, seconds (same as "hmS")

Other Date Related Functions


An ultra-liberal, locale-aware date parser


An ultra-liberal, locale-aware time parser

formatDuration(t0, t1, ms)

Generates the Viewpoint standard duration representation of the difference between two timestamps. The output is [days+]0:00:00 unless the ms flag is true.

parseDuration(string, format, strict)

Converts the user's input into a millisecond value. The default format includes milliseconds, but other formats can be "teradata" or "seconds".

formatTeradataDuration(HHHMMSSCC, ms)

Displays a Teradata duration in in the Viewpoint standard duration format. The output is [days+]0:00:00 unless the ms flag is true.