1
-
Hi Amy,
Yes, setting the GMT offset in the tenant will apply to all of your timestamp fields. The setting change does require restarting Analytics service. Alternatively, you can adjust time zones on a field-by-field basis with the addMinutes() function in formula column or insight. A more full-featured timezone function is on the product roadmap.
Thanks,
Dustin
-
Dustin Basil is it valid on most recent incorta versions?
-
Siva Kowsika No, this is not valid on recent versions. Incorta will reflect the timezone of the server it is installed on. To change the displayed timezone, you can either change the server OS timezone or pass desired timezone to the JVM running Incorta and perform a staging load of all Schemas. I recommend customers not comfortable with this process reach out to Incorta support for more detail or assistance. Steps below:
The steps to change the JVM timezone is as below:
1. backup the file 'startService.sh' located under '<incorta_installation_path>/IncortaNode'
2. edit the file changing the line below
from:export JAVA_OPTS="-Xms"$memorySize" -Xmx"$memorySize" -Dfile.encoding=UTF-8"
To:
export JAVA_OPTS="-Xms"$memorySize" -Xmx"$memorySize" -Dfile.encoding=UTF-8" -Duser.timezone=America/Los_Angeles
3. the above change to be done on both loader and analytics nodes.
4. restart the services.
5. do a full load from staging -
I have tested this in our environment and I've tried both changing the time zone on the EC2 server OS and using your method within the startService script. I changed our time zone from UTC to America/Chicago, which was a change of - 6 hours.
A couple of notes about changing the time zone....
Changing the time zone on the OS caused the time stamps of our loads to be off by 6 hours. All loads were shown as occurring 6 hours before they had actually run. (On AWS EC2 Linux there's a link in /etc called 'localtime' that you have to change)
Changing the time zone in the startService script did not affect the load times on the Schema page.
Both methods affected the 'last modified' date on dashboards and Last Login on the Security page. Any recent modification showed as occurring 'In 6 Hours' - as in - the last login or change was in the future. All times were off by 6 hours.
Just a couple things to be aware of if you change the time zone.
-
Mike Mascitti Hi Mike, how are the timestamps being passed in from your source system? This can affect incrementals too if they Incorta server time and the source system time aren't in agreement or aren't both agnostic based on GMT.
-
Dan Brock Hi Dan - Yes, we also had an issue with an incremental load. Our source system has a date column as part of the key, but it's not a datetime.
Data with duplicate primary keys was retained for the first incremental run done after changing the time zone on the OS. Subsequent incremental loads with matching primary keys overwrote the data made after the time zone change. It was as if there is an internal time stamp being used on the logic that determines if a key is unique.
I thought this was 'user error' because I hadn't restarted the services after making the change to the time zone. When I tried again in a second environment I restarted everything after making the change, and the incremental load worked as expected.
-
