Versions Compared

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

...

...

...

...

...

...

...

...

Table of Contents

Syntax

SHIFTTIMEZONE(<date>;<Time Zone 1>;<Time Zone 2>)

Description

...

This function allows you to assign a timezone time zone to values in a date type column  column and then shift the date values to a different time zone.The result of the function has a date column with the dates displayed in the Datameer instance's local timezone 

<Time Zone 1> is the time zone you want for the final values, <Time Zone 2> is the current time zone for the values being shifted. Time Zone 1 is usually the time zone of the Datameer application server or the user's time zone (if different).


Info
title
icontitlefalseINFO

Information on time and date data within Datameer pertaining to timezones:

  • Datameer internally stores all dates as universal time (UTC)
  • .
  • Datameer displays dates within
  • Workbooks
  • workbooks as a local time for your Datameer instance
  • .
  • Datameer recognizes the
  • timezone
  • time zone for dates with an included parsed
  • timezone.
  • time zone
  • Datameer assigns
  • the
  • your local instance
  • timezone
  • time zone to dates parsed without a
  • timezone.

...

  • time zone
Info
titleINFO

Time zones available for the

...

function's arguments can be found at http://joda-time.sourceforge.net/timezones.html

...

Examples

...

.

Info
titleINFO

Datameer always uses the following format for displaying dates:

Three character month abbreviation (space) two-digit day (comma)(space) four-digit year (space) two-digit hour (colon) two-digit minute (colon) two-digit second (space) two-character meridiem notation.

(e.g., 12.01.2012 gets transferred to Jan 12, 2012 12:00:00 AM)

When selecting a pattern, you select the way the data gets parsed (your input format, this can be connected to your systems representation of dates and times).

Use-case 1

Datameer application server runs in the CET time zone (Berlin). A user located in Berlin, Germany has pulled in log files from a server located in Los Angeles, USA. The server logs all data using the local time zone but the dates extracted from the log files had have no assigned time zone stamp assigned.

...

These dates are currently being displayed in local time for the user's Datameer instance which is in Berlin. (GMT+2). The problem is that these time stamps for the log events that happened during Pacific time (GMT-7).

The SHIFTTIMEZONE function lets the user assign a timezone to a date column and then reassign it to a new timezone which updates the displayed results.

Below, the timezone for Berlin, Germany is being assigned, in the "From Timezone" field, as the initial incorrect timezone. The second field, "To Timezone", is assigning the date to be correctly identified in the Los Angeles, USA timezone.

The timezones are being shifted from GMT+2 to GMT-7.. Because there is no time zone stamp, the user's machine interprets the log entries as happening in their local Berlin time. The SHIFTTIMEZONE function lets the user correct this by declaring the time zone they want for analysis "Europe/Berlin" (Time Zone 1) and the time zone that the data is currently in "America/Los_Angeles" (Time Zone 2). 

Formula builder
SHIFTTIMEZONE
Date#Log_Time
From Timezone
Clarification (not available in Datameer UI)
Time Zone 1Europe/Berlin
To Timezone
The time zone you want for final analysis
Time Zone 2America/Los_AngelesThe

...

Here, the log time is now being shown correctly in Berlin, Germany (local server time) for the log events that took place in the Los Angles, USA timezone.

Log_TimeTimezone corrected log timeJul 15, 2015
current time zone for values being shifted

Log_Time

Raw data (events occurred during Pacific time)

SHIFTTIMEZONE(#Log_Time;"Europe/Berlin";"America/Los_Angeles")

Pacific timestamps represented in users time zone (Berlin)

Jul 15, 2019 02:00:00 AMJul 15,
2015
2019 11:00:00 AM
Jul 15,
2015
2019 03:00:00 AMJul 15,
2015
2019 12:00:00 PM
Jul 15,
2015
2019 04:00:00 AMJul 15,
2015
2019 01:00:00 PM
Jul 15,
2015
2019 05:00:00 AMJul 15,
2015
2019 02:00:00 PM
Jul 15,
2015
2019 06:00:00 AMJul 15,
2015
2019 03:00:00 PM
Jul 15, 2015 07:00:00 AMJul 15, 2015 04:00:00 PM Jul 15, 2015 08:00:00 AMJul 15, 2015 05:00:00 PM Jul 15, 2015 09:00:00 AMJul 15, 2015 06:00:00 PM Jul 15, 2015 10

Use-case 2

A server registering events occurring in Los Angeles, USA is set to use UTC time zone and has not been configured to record any time zone in log entries.  A user has pulled in log files from this server. The dates extracted from the log files have no time zone stamp assigned and represent UTC time. The SHIFTTIMEZONE function lets the user correct this by declaring the time zone they want for analysis "America/Los_Angeles " (Time Zone 1) and the time zone that the data is currently in "UTC" (Time Zone 2).

Formula builder
SHIFTTIMEZONE
Date#Log_TimeClarification (not available in Datameer UI)
Time Zone 1America/Los_AngelesThe timezone you want for final analysis
Time Zone 2UTCThe current timezone for values being shifted

Datameer always uses the following format:

Three character month abbreviation (space) two digit day (comma)(space) four digit year (space) two digit hour (colon) two digit minute (colon) two digit second (space) two character meridiem notation.

...

Log_Time

Pacific timestamps represented in the server's time zone (UTC)

SHIFTTIMEZONE(#Log_Time;"America/Los_Angeles";"UTC")

Real events timestamp according to the source local time zone

Jul 15, 2019 02:00:00 AMJul
15
14,
2015
2019 07:00:00 PM
Jul 15,
2015 11
2019 03:00:00 AMJul
15
14,
2015
2019 08:00:00 PM
Jul 15,
2015 12
2019 04:00:00 AMJul
15
14,
2015
2019 09:00:00 PM
Jul 15,
2015 01
2019 05:00:00
PM
AMJul
15
14,
2015
2019 10:00:00 PM
Jul 15,
2015 02
2019 08:00:00
PM
AMJul 15,
2015 11:00:00 PMJul 15, 2015 03:00:00 PMJul 15, 2015 12:00:00 AM

...

2019 01:00:00 AM

...