Local_dt HUBL variable is returning date an email was scheduled

Developer Support CMS Development
1

We’re using local_dt to get the date and time an email is sent. This has been working fine for us as most of our emails are not scheduled. However, we had an email that was scheduled yesterday to send this morning, and local_dt output yesterday’s date instead. We did some further testing and found out that in fact, the date and time an email is scheduled locks in as the local_dt value.

It doesn’t seem like that should be the case. The documentation doesn’t note that:

“A datetime object of the current time in the time zone defined in your Report Settings.”

It seems like the expected value of local_dt should be the date and time the email is sent.

We had been looking at using content.publish_date, but that caused issues with our RSS emails.

Is this a bug? Is there a better way to get the send date of the email?

2

Hi, @mnorman :waving_hand: Thanks for reaching out. Hey, @BarryGrennan @miljkovicmisa, do you have any HubL-related troubleshooting wisdom you can share with @mnorman?

Thank you! — Jaycee

3

I’m also facing the same issue. Please advise.

4

I am having this same issue. Was this supposed to be resolved?

5

Hey @KMausner,

local_dt is set to eastern time(EDT) by default.

This may result in a different time - depending on your location.

For example:

I’m located in Germany, it’s 9am in the morning - if I add {{ local_dt }} somewhere, I’m getting 3am as a result.

To address this, use the format_datetime filter so {{ local_dt }} becomes something like {{ local_dt | "medium", "Berlin/Germany", "de-DE" }}

Of course you can modify it way further like

  • {{ local_dt | "dd.mm.yyyy", "Berlin/Germany", "de-DE" }} // will display the date only
  • {{ local_dt | "hh:mm", "Berlin/Germany", "de-DE" }} // will display hours:minutes only
  • …

A full list of possible modifiers/filters can be found in the Unicode list

p.s. If you’re looking for a different variable, here’s the full list

best,
Anton

Moderator note: While this solution may not address the original poster’s specific situation, it could be helpful for other community members facing similar challenges.

6

I would separate two issues here.

Timezone formatting can change what you see, but it does not solve the scheduled-email case from the original post. For scheduled marketing emails, HubL is rendered before the actual send event, so a “current time” variable can reflect the render/schedule moment instead of each recipient’s final send time.

If the exact sent date matters, I would avoid relying on local_dt inside a scheduled email. Safer options are:

  1. Use a fixed campaign/send date property if the date is known.
  2. Stamp a contact/deal property in the workflow before the email step, then use that token.
  3. For RSS or recurring emails, test one scheduled send and one immediate send in a clone before using it in production.

So yes, format the timezone for display, but do not treat local_dt as a reliable per-recipient send timestamp for scheduled emails.

11

Hi that is not the issue. I need non-automation sends to set to date it’s SEND, not when it was SCHEDULED. Right now, if I schedule on Wed for a Fri send, it shows the customers the Wed date. This is a liability for promotions.

12

These are not sustainable or ideal. Local_dt has a bug that needs to be fixed for scheduled emails.

14

Hi @KMausner and thank you for following up and sharing your perspective.

I understand how important it is for scheduling data to be accurate in all scenarios. The current behavior of local_dt is actually expected, it captures the time when the email is scheduled, not when it’s sent, due to how our system pre-renders batch emails.

In HubSpot, batch emails are actually pre-rendered when you schedule or publish them, not when they’re sent. The first rendering step (handled by cos-renderer) occurs as soon as you hit “Schedule”, at this point, the HTML is created and stored for later delivery. As a result, local_dt gets its value right at this scheduling moment, rather than at the send time.

The rendering process works in two phases: the initial pass pre-renders everything that isn’t specific to a contact (including local_dt). Then, a lighter second pass happens for each recipient, focusing on details like personalization tokens (for example, {{ contact.firstname }}). Since local_dt is a global variable and gets set during the first pass, there’s no built-in way to have it reflect the actual send time.

While this isn’t ideal for all use cases, especially scheduled sends, it’s not considered a bug, but rather a limitation of our existing architecture.

Your feedback is valuable and helps us prioritize future improvements so I’ve passed it along internally so that we can clarify the documentation regarding this point.

I’ll check for potential workarounds and will update the thread if there are any.

If you have any other questions or need further clarification, I’m happy to help!

Bérangère

This post was created with the assistance of AI tools

18

Hi @cartergray3333, I hope that you are well!

Thank you for sharing your valuable feedback with the HubSpot Community!

I’ve passed it along internally so that we can clarify the documentation regarding this point.

Have a lovely day!
Bérangère