Scheduled Alert Time Changed By Itself??

I'm in Eastern time zone. My regional settings are set that way, both personally and for the organization.

I created two new automation rules back in July 2022. The alerts run on Mondays and Wednesdays at 12pm Eastern. When I looked this morning, the scheduled times were showing 9am Eastern, and indeed they ran at 9am Eastern, screwing up some workflow (since users are supposed to have until 12pm to make their changes that determine what gets included in the alerts.) The modified date on the rules was the same as the day I created them.

How did these switch from 12pm to 9am on their own?

(I'm not the sheet owner, but am a licensed Admin on the sheet. I confirmed with the sheet owner that his time zone is set to Eastern and that he hasn't messed with it. Sheet ownership changed on 8/18/22, but both users work here in the building and are set to Eastern time.)

Find more posts tagged with

Accepted answers

All comments

Meg Y

After reading your post I went in checked my automations and they were changed too.

The time zones now read

I am not sure when this change happened. My automation was created last week and the time was US/Central.

Jeff Reisman

@Meg Y

Was your automation originally scheduled for 6:00 AM US/Central?

Meg Y

It was scheduled for 9:00 AM US/Central.

Smartsheet rolled it back to 4:00 AM US/Central GMT (-5 hours)

Now, I will need to set my time to 2:00 PM US/Central GMT (-5 hours) for a 9:00 AM alert.

https://greenwichmeantime.com/time-zone/usa/central-time/

GMT is still hard for me to understand.

Genevieve P.

Hi @Jeff Reisman & @Meg Y

I've checked in with other accounts that have EST or MST account settings and their workflows have been running at the correct time (without changing).

One thing to clarify is that the "last ran" time showing underneath the workflow is based on your computer's timezone, not necessarily the Account settings or the Workflow timezone.

So if I'm currently based in PST and that's my computer's time, but the Automation is built in EST based on my Account settings, the workflow will run based on what you've configured in the workflow, but the display value for "Last ran" will show you based on your computer time. Does that make sense?

Meg Y

@Genevieve P.

The time the automation runs make sense based on my account settings.

What I don't understand is how my settings switched (GMT-) US/Central.

When I checked earlier it was set to US/Central Chicago. Now it is back to (GMT-5) US/Central.

Jeff Reisman

@Genevieve P.

When I built the automations on 7/25, here in Eastern time with Eastern settings, I set them to run at 12pm on Mondays and Wednesdays, which they did for the next 3 weeks or so.

On Wednesday 8/17 the automations ran at 12pm Eastern as expected. The sheet owner, me (as the automation creator,) the alert recipients... everybody's laptops are on Eastern time, everyone's regional settings are set to Eastern time. On Thursday 8/18 sheet ownership was transferred from one guy to another who sits two cubicles away, whose system/settings are also Eastern. On Monday 8/22, and every Monday/Wednesday after that, the automations ran at 9am Eastern. I know this because I have a screenshot from a user in our building, showing the alerts received correctly at 12pm on 8/17, and then incorrectly at 9am on 8/22. When I looked at the automations yesterday morning, the Last Modified info showed they were last modified by me on the day I created them, 7/25, yet they were set to run at 9am Eastern.

I think this was another case of Smartsheet's complicated handling of datetime values behind the scenes fouling up. Maybe it was just a glitch, or a bug that was found and corrected since? Here's what I've been able to determine over 3.5 years of working with Smartsheet. Tell me if I'm off base:

Smartsheet stores datetime values at their database level in GMT/UTC. So 12pm Eastern Daylight Time would be 4pm GMT. At the server level, Smartsheet converts the stored GMT time to the server local time. So 12pm EDT on a USA West Coast server would be 9am PDT. At the presentation level, Smartsheet converts the server time of 9am PDT to the time zone setting of the logged in user, which for me here in Eastern would be 12pm EDT.

(This is why in the past I've had issues using the system columns Created date and Modified date to perform proper date calculations - because instead of a row created at 10/20/22 1:35 AM EDT being counted as being created on the same day as a row created on 10/20/22 3:05 AM EDT, the system counts these as being created on 10/19/22 10:35 PM and 10/20/22 12:05 AM.)

With my automations, I think there was a glitch when the ownership was changed, whereby the HOUR of the server time for the automation (9am PDT) was kept, but then the time zone was changed back to EDT without also readjusting the hour to 12pm. That's the only thing that could explain this, as all the players involved had system times and settings time zones set to Eastern.

Jeff Reisman

@Genevieve P. Here's another example from the same sheet, different automation. This screenshot of the automation preview is from just now:

It shows scheduled for Sundays at 10pm. When I modified this rule on 5/3/22, I scheduled it for Mondays at 1am. Here it shows that it last ran Sunday 10/16 at 10pm, and that the rule has not been modified since 5/3/22.

On Monday 8/15, when the sheet was owned by Kurt, the users received the alert properly on Monday at 1:01 AM EDT:

The sheet changed ownership on Thursday 8/18. Note that both sheet owners and the alert recipients are all in Eastern time, physically and per their PC, Email and Smartsheet settings.

Now owned by Austin, the alert ran three hours earlier than expected on the following Sunday 8/21 at 10:00 PM, as shown here:

So how does the automation get changed to run 3 hours earlier than it did before, without the rule showing that it was modified??

Genevieve P.

Hi @Jeff Reisman

Thank you for all of this detailed information! You're right, Smartsheet has some complicated ways of handling dates. I'm unsure if your current experience is related to the ownership change, although your hypothesis does sound plausible.

We will need to do some testing to see if we can replicate this - so far I have not seen any other reports come in around times changing in workflows when transferred. At this point I would recommend contacting Support with all of the same information you provided to me, and additional sensitive data that they can troubleshoot in a private channel (e.g. direct sheet link, email addresses of the current owner, Workflow ID).

I'll check in on this next week and try to replicate with my own workflows as well.

Cheers,

Genevieve

Sign in to join the conversation!

Quick Links

Component react.discussion.discussions had an error.

ref must be one of: categoryID, siteSectionID, category, category/categoryID, category/name, category/description, category/url, category/allowedDiscussionTypes, locale, siteSection, siteSection/basePath, siteSection/contentLocale, siteSection/sectionGroup, siteSection/sectionID, siteSection/name, siteSection/description, siteSection/apps, siteSection/attributes, layoutViewType, discussionID, commentID, page, latest, sort, sortType, lookupSort, discussion, discussion/name, tags, breadcrumbs, discussionApiParams, serverDraftID, serverDraft.