{{current_time}} variable broken in some configurations

Support Help
1

Been pulling my hair out for hours over this!

I have one agent where the dynamic variable {{current_time_America/Los_Angeles}} consistently returns a date in the past. I am certain that it is being used correctly. In all my other agents, it is functional

I tried to duplicate the agent and lo and behold, it returned the correct date and time in the copy.

It seems that there is some sort of cacheing issue in the malfunctioning agent? Any have any experience with this or know what could have caused it? It is certainly something I would like to avoid in the future.

Thanks

2

Your experience matches a known issue with the {{current_time_America/Los_Angeles}} dynamic variable.(1)

The recommended solution from the Retell team is to duplicate your existing agent to get the latest dynamic-variable support.(1) This should resolve the caching issue you’re experiencing.

Additionally, when using the duplicated agent:

  • Use it in a live inbound call (not simulation)(1)
  • Ensure the prompt includes a fallback default in case time fails(1)

The {{current_time_America/Los_Angeles}} variable should provide the current time in the specified timezone in the format “Thursday, March 28, 2024 at 11:46:04 PM PST”.(2) You can also use the general {{current_time}} variable which defaults to America/Los_Angeles timezone, or specify other timezones using the format {{current_time_[timezone]}}.(2)

Since duplicating resolved your issue, this confirms it was likely a backend versioning problem with the original agent that prevented it from accessing updated dynamic variable functionality.

3

Thanks,
{{current_time}} seems to returning the correct date in both agents (original and copy).

{{current_time_America/Los_Angeles}} only returns the correct date in the copy.

Any speculation as to the root cause of why the original agent got stuck? Is it something that can be prevented on my end? I am worried about this happening again during production.

Thanks

4

Based on the available sources, I don’t have specific information about the root cause of why {{current_time_America/Los_Angeles}} got stuck in your original agent while {{current_time}} continued working.

However, there’s a similar documented case where a system dynamic variable ({{user_number}}) had caching issues. In that case, the user found that after setting a fallback dynamic value and then deleting it again, the variable started working correctly.(1) The user noted: “Strange. I dont know if you guys fix something from backend but this is what I see”.(1)

This suggests the issue may be related to how the platform handles certain dynamic variables at the agent level, potentially involving backend caching or version compatibility.

To minimize risk in production:

  1. Test dynamic variables in live calls (not just simulations) before deploying(1)
  2. Set default dynamic variables at the agent level as fallbacks using the default_dynamic_variables field(2)(3)
  3. Monitor for unexpected values and consider duplicating agents if variables behave inconsistently

Unfortunately, without more technical details from Retell’s engineering team, there isn’t a definitive preventive measure on your end beyond these best practices. If this becomes a recurring issue, I’d recommend reaching out through these support channels: