📩 Learning 9 - The Car Clock Never Springs Forward: A Journey That Resumed an Hour Late Because of Daylight Saving Time

Lakshmi Pavani

— 2 min read

Recently, I paused a Journey in Salesforce Marketing Cloud (SFMC) Journey Builder on a Friday at 3 PM and scheduled it to resume automatically on Monday.

I expected it to be active again from 3 PM Monday. It wasn't.

After a moment of panic, I contacted SFMC Support. They confirmed it: Journeys resume based on CST (Central Standard Time), not your local time. Over that weekend, Daylight Saving Time had started in Australia.

If a Journey is scheduled to resume after DST starts, does the resume time automatically shift with the clock change?

After a moment of panic, I contacted Salesforce Marketing Cloud Support. They confirmed the cause: the Journey resumes based on CST (Central Standard Time), not my local time. Over that weekend, Daylight Saving Time had started here in Australia.

That reminded me of something very ordinary from everyday life: the clock in the car.

🚗 The Scenario: The Clock That Never Changes

When Daylight Saving Time starts, your phone moves forward an hour on its own. The car clock doesn't. It keeps ticking as if nothing happened.

Neither clock is broken. They just follow different rules.

📱 The Phone = My Local Time (Sydney)

On Sunday, Sydney moved from AEST (UTC+10) to AEDT (UTC+11). When I planned "resume Monday at 3 PM", I was reading the phone.

🚘 The Car Clock = SFMC System Time (CST)

SFMC runs on CST (UTC−6) all year and doesn't move for DST. When it scheduled the resume, it was reading the car clock.

When SFMC scheduled the resume, it was reading the car clock.

⏰ The Hour That Went Missing = The Gap Between the Two Clocks

Before the weekend, the two clocks were a fixed distance apart. After DST started, my phone jumped forward, but the car clock stayed put, so the gap between them changed by one hour.

Friday 3 PM Sydney (AEST) = Thursday 11 PM CST
The Journey resumed at that same CST time on Sunday
Sunday 11 PM CST = 4 PM Monday Sydney (AEDT)

SFMC did exactly what its clock said. I was simply reading a different clock.

💡 What I Learned

My first instinct was that something had gone wrong with the Journey, or that the resume hadn't been saved properly.

But the issue wasn't the configuration. It was which clock was being used to read it.

Like the car clock, SFMC's system time doesn't spring forward. Customers in the US get used to this. For those of us outside the US, it's easy to get caught twice a year, and in different months from the US clock changes.

📌 Key Takeaways for SFMC Practitioners

  • SFMC system time is CST all year and doesn't change for Daylight Saving Time.
  • A local DST change can make a Journey resume an hour earlier or later than expected.
  • If a pause spans a DST change, convert the resume time to CST and back to your local time.
  • Check important Journeys just after the planned resume time.
  • Write down this behaviour for your team.

🧭 Conclusion

A correctly configured Journey can still resume an hour late if you and SFMC are reading different clocks.

Before scheduling around a Daylight Saving Time change, ask: "Is this system reading my phone, or the car clock?" 😊

Note: These are simply my observations and learnings. Always refer to official Salesforce documentation and Salesforce Support guidance for the most accurate and up-to-date information.

Salesforce Help article:

https://help.salesforce.com/s/articleView?id=mktg.mc_server_timezone_changes.htm&type=5

I hope you found this useful. If you've run into this "found it manually, but the automation says otherwise" pattern before, I'd love to hear how you solved it. 🚀

Read more