I investigated whether it's possible to get the current date and time within a Twilio Studio flow without using a Function

Introduction

Twilio Studio is a Twilio feature that lets you build inbound call and SMS flows through a GUI. It comes in handy when you want to keep logic such as IVR, call tracking, or SMS auto-responses contained within Twilio. In these scenarios, a common need arises to obtain the current date and time mid-flow and include it in a Webhook notification to your own API.

The straightforward implementation is to prepare a single Twilio Functions (a serverless feature that can run Node.js) and simply return new Date().toISOString(). However, when there is a constraint of "completing everything within Studio without using Functions," the question becomes whether you can obtain the current date and time using only Studio's standard widgets. Being able to do so entirely within Studio means the entire flow can be maintained through GUI edits alone, reducing the burden on non-engineer operators.

This article comprehensively examines both Liquid templates in the Set Variables widget and the context variables provided by Twilio Studio, clarifying the methods and limitations of obtaining the current date and time without using Functions.

Conclusion

The conclusion is as follows.

• Obtaining the current date and time is possible without using Functions. The working syntax is the following single option:

  {{ "now" | date: "%Y-%m-%d %H:%M:%S" }}
  

However, the timezone of the returned time is fixed to PDT/PST (US Pacific Time), and no method was found within the tested scope to convert to UTC or output a timezone-annotated representation inside a Studio flow. As a result, when you need to handle time in JST or UTC, one of the following approaches is required:

• Convert the time on the receiving server
• Recalculate using the call start time and call duration in seconds
• Allow a single minimal Function

Verification Environment

• Twilio Studio Flow (built with widget placement only, Functions not used)
• Flow creation and execution via Twilio REST API (called directly with curl)
• Receiving endpoint: a disposable URL from webhook.site
• Verification date: May 2026

Target Audience

• Those building or considering IVR or call-tracking flows with Twilio Studio
• Those who want to design flows that are self-contained in Studio without using Twilio Functions
• Those interested in the actual variables and filters available in Studio's Liquid templates
• Those having trouble with timezone handling when including time information in Webhook notifications

References

• Twilio Studio
• Set Variables Widget
• Make HTTP Request Widget
• Liquid Reference

Verification Method

The verification was conducted with the following configuration.

Multiple Liquid syntaxes are lined up in the Set Variables widget, and they are all POSTed together to webhook.site via the Make HTTP Request widget.

The Set Variables widget portion of the Flow definition JSON looks like this:

{
  "name": "set_now",
  "type": "set-variables",
  "transitions": [
    { "next": "send_http", "event": "next" }
  ],
  "properties": {
    "variables": [
      { "key": "now_a", "value": "{{ \"now\" | date: \"%Y-%m-%d %H:%M:%S\" }}" },
      { "key": "now_d_sanity", "value": "{{ flow.flow_sid }}" }
    ]
  }
}

In the Make HTTP Request widget's Body, each variable is referenced in the format {{flow.variables.now_a}}. When received at webhook.site, you can see how each syntax was evaluated as the value of each key in the POST Body.

After building the Flow, it was executed by directly calling the Twilio REST API with curl.

curl -s -X POST "https://studio.twilio.com/v2/Flows/${FLOW_SID}/Executions" \
  -u "${SID}:${TOKEN}" \
  --data-urlencode "To=+81**********" \
  --data-urlencode "From=+1**********"

Verification 1: Retrieving the Current Time with Liquid's date Filter

The first thing tried was the pattern of passing the string "now" to the date filter commonly used in Liquid. Since it is known that {{ "now" | date: "..." }} can format the current time in Shopify Liquid, this verification confirms whether it works the same way in Twilio Studio.

The fact that now_a worked confirms that the current date and time can be obtained with Studio alone without using Functions. It is also clear that the strftime format %Y-%m-%d %H:%M:%S is supported in Twilio Studio's Liquid implementation.

On the other hand, the %s format for obtaining Unix epoch and the date_to_rfc3339 filter available in Shopify Liquid were not supported. In particular, now_c returned the entire Liquid as a literal without being parsed, revealing the behavior where Twilio Studio's Liquid implementation returns a literal as a fail-safe when a filter is unsupported.

Verification 2: Looking for Syntax to Handle Timezone Information

Staying with PDT is problematic for use cases that require handling time in JST or UTC, so the next step is to look for a way to obtain or convert timezone information. The following three syntaxes were tested as candidates.

All three syntaxes failed in their timezone-related attempts. With now_e, the time itself is obtained, but the timezone offset format (%z) is not interpreted and is embedded as a literal string. The plus filter in now_f is for numeric operations, and attempting to add seconds to the string "now" causes the entire Liquid to fail parsing. The %F (year-month-day), %T (hour-minute-second), and %:z (offset notation) formats tested with now_g are none of them included in Twilio's strftime implementation.

From this point, it became clear that there seems to be no way to perform timezone conversion with Liquid's date filter.

Verification 3: Checking Whether Twilio Context Variables Include UTC Time

Since Liquid filters are a dead end, the next check is whether any of the context variables provided by Twilio Studio in the Flow Execution context include UTC time. In Twilio Studio, various metadata can be referenced from the flow.*, trigger.*, and widgets.* namespaces.

flow.sid is returned correctly as the Execution SID, but it is not time information itself. trigger.request can retrieve the parameters passed with the REST API trigger, but does not include a timestamp. flow.data is returned as an empty object, and based on a search of the documentation, no key corresponding to the Execution start time appears to be publicly available.

As a result, it became clear that there also seems to be no path to obtain UTC time through Twilio context variables.

Why Timezone Conversion Is Not Possible

Based on the verification results, the following is a consideration of why time processing flexibility is limited in Twilio Studio.

Twilio Studio's Liquid implementation appears to provide only a subset of filters from standard Shopify Liquid. The basic patterns for the date filter and strftime format are supported, but offset notation %z, ISO 8601 shortcut formats %F, %T, and %:z are not included in the implementation. Also, Liquid's plus filter is defined in Shopify for addition operations on numeric types, and applying it directly to a string like "now" is not an intended use case, so Twilio behaves the same way.

In addition, the context variables for Twilio Studio's Flow Execution are confined to the parameters at trigger time and the output results of Widgets. While the metadata for the entire Flow Execution (such as the creation time) can be obtained as date_created via the REST API, no means of referencing it from Liquid within the Flow is provided.

Together, these factors form the structure that makes "converting the current time to JST or UTC within a Studio flow" an operation that cannot be handled server-side at all.

Practical Options

Since timezone conversion cannot be done within a Studio flow, time processing must be absorbed outside of Studio. In practice, three options are conceivable.

1. Send from Studio in PDT notation and convert to UTC or JST on the receiving server
   JST can be obtained on the receiving side by adding a fixed offset of +16 hours (during PDT) or +17 hours (during PST). For operations that span daylight saving time transitions, handling the one-hour discrepancy also becomes a consideration.

2. Do not send time from Studio; instead, use the time received on the receiving server
   If the server-side now() is captured at the moment the Webhook fires from the Studio flow, the time can be recorded with a difference of a few hundred milliseconds to a few seconds compared to the time sent from Studio. If second-level precision is not required for the end-of-call timestamp, this is the simplest solution that completely eliminates the timezone problem.

3. Prepare a single minimal Function solely for obtaining the date and time
   By placing a Function like the following three lines and calling it from the Studio flow via the Run Function widget, the time can be obtained in UTC ISO 8601 format.

   exports.handler = function(context, event, callback) {
     callback(null, { now: new Date().toISOString() });
   };
   

   Unless there is a strong requirement to avoid using Functions entirely, this approach is simple to implement and maintain, and keeps the burden on GUI-based operators small as well. In many cases, the practical compromise is to draw the line at avoiding writing business logic in Functions while allowing a "minimal Function just for date/time retrieval."

Summary

This article verified whether the current date and time can be obtained within a Twilio Studio flow without using Functions. In conclusion, retrieval itself is possible with {{ "now" | date: "%Y-%m-%d %H:%M:%S" }}, but it became clear that attaching or converting timezone information cannot be done with Studio alone. This is thought to stem from the structure of Twilio Studio's Liquid implementation providing only a subset of filters, with Flow Execution metadata also being inaccessible from Liquid.

In practice, the choice comes down to either converting the time on the receiving side, using now() on the receiving side, or allowing a single minimal Function just for time retrieval. We hope this serves as a useful reference when deciding how to handle timezones when designing Studio flows.