Skip to main content
New Idea

Standardize Time Zone Display Across Application

Related products:CS Data Management & IntegrationsCS Rules EngineCS Connectors
  • October 17, 2025
  • 11 replies
  • 145 views

romihache
Forum|alt.badge.img+9

Problem

Gainsight CS displays execution history and related time-sensitive data using inconsistent time zones across different features, leading to confusion, wasted time, and the need for manual time zone conversions. Lack of time zone parity across features creates an unnecessary cognitive load for users trying to understand the status and timing of critical processes and workflows.


When investigating why a specific user was missing on my end, I checked the execution time of the relevant Job (Salesforce connector).

  1. The Job's history showed the last run was yesterday at 7:00 AM.

  2. Knowing it’s a daily run, I expected it to have already executed today as it was 8:45

  3. Upon checking the Job's configuration, I realized the execution time was set to 7:00 AM PDT (the application's time zone), which corresponds to 4:00 PM in my local time.

  4. This caused me to mistakenly believe the execution was missing and required me to manually trigger the job; all because the displayed time was not in my local context.

Connectors → Activities UI


The root cause of this confusion is that I spend most of my time in the Rules Engine, where the execution history is displayed in my local time zone. When I switch to Connectors 2.0, the time zone shifts to the application's default. This broken experience forces users to perform "mental gymnastics" and consult external converters just to confirm the expected run time.

 

Proposed Solution

 

I request a feature to allow users to select the time zone for displayed data within each feature that shows execution history or timing (e.g., Jobs, Rules List, Rule Chain, etc.).

Ideally, this would function similarly to the Rules Engine → Activity view, but be integrated directly into the feature's interface, not as a separate activity section.

 

Rules Engine → Activity allows users to select the time zone for displaying data


Example Implementation:

Introduce a prominent UI element (like a toggle or dropdown) that allows the user to switch the display of time-stamped data between:

  1. Application Time Zone (e.g., PDT)

  2. User's Local Time Zone (The time zone of the user browsing the app)

 

Mockup: Allow the user to select the display time zone, dynamically adjusting all dates and times shown in the UI


Standardizing the display across all features will prevent user error, reduce support inquiries, and greatly improve the overall user experience.

#adminQoL

11 replies

Molly.McQ
Forum|alt.badge.img+2
  • Helper ⭐️
  • October 17, 2025

+1, this is unnecessarily complicated and tedious for admins. Standardization, as Romi proposed, would be a major improvement in this arena. 


TMaier
Forum|alt.badge.img+5
  • Helper ⭐️
  • October 20, 2025

Yes please! Going a step further, it would be great if we just added the TZ code based on the conversion being applied directly on any Date / DateTime fields being displayed across any element of Gainsight.


romihache
Forum|alt.badge.img+9
  • Author
  • VIP ⭐️⭐️⭐️⭐️⭐️
  • October 20, 2025

Yes please! Going a step further, it would be great if we just added the TZ code based on the conversion being applied directly on any Date / DateTime fields being displayed across any element of Gainsight.

Brilliant! 


bradley
Forum|alt.badge.img+8
  • Expert ⭐️
  • November 18, 2025

There must be like a 7 year old post about this…

First make sure we can tell what the time zone is for any given area but yes - please let us standardize the display (and for the love of, make it a sticky setting and not force everyone to reset it constantly).


darkknight
Forum|alt.badge.img+5
  • Expert ⭐️
  • January 15, 2026

This is SUPER annoying. Can we please get some PM eyes on this?


TMaier
Forum|alt.badge.img+5
  • Helper ⭐️
  • January 15, 2026

Agree! Due to the issues in November, I had to do a lot of rescheduling recently and keeping my connectors, DD’s, JO Programs, and Rules all set to run in the expected order was a bit of a challenge because I had to try to remember what TZ conversion to apply to which context etc etc.

This is an area where it would pay dividends to be clear and precise.


dayn.johnson
Forum|alt.badge.img+7
  • VIP ⭐️⭐️⭐️⭐️⭐️
  • January 15, 2026

Please!

While it would technically be feasible for an org to say “we’re going to do everything in UTC” – for organizations based in a different time zone, that would likely lead to a LOT of errors as everyone tried to figure it out. Sync/schedule timezone should be immediately visible when looking at different product areas.


dcassidy
Forum|alt.badge.img+6
  • Helper ⭐️
  • January 15, 2026

I couldn’t agree more - we really need parity here. This is another in an ever-growing list of items that take away from admin quality of life. We have enough on our plates (especially recently) without having to remember what piece of the product is in which time zone. 


mobrien14
Forum|alt.badge.img+6
  • Helper ⭐️
  • January 15, 2026

Agreed with all of the above, the lack of uniformity & parity has definitely led to a number of timing issues or accidental misses. Please prioritize this.


bradley
Forum|alt.badge.img+8
  • Expert ⭐️
  • January 15, 2026

Also, shout out to hoping support also includes the time zone when they talk about things considering there’s also no consistent datapoint to check it against in the platform either, when you’re trying to discuss something.


alizee
Forum|alt.badge.img+13
  • VIP ⭐️⭐️⭐️⭐️⭐️
  • January 23, 2026

It should show any date and date time value across the system in the user’s selected time zone. Whether that’s fields in objects, or other fields like rule runtime data and other admin-only timestamp data points such as logs.