Make.com date and time formatting is not only a presentation task. The format you choose affects whether another system can parse a value, whether a user understands a notification, and whether a report groups records correctly.
In practice, reliable datetime handling has three separate parts: the source value, the formatting pattern, and the timezone used for interpretation or display. A token pattern can control the visible structure, but it cannot repair a missing timezone, an ambiguous source date, or a workflow that applies different conventions in different scenarios.
Use numeric, sortable formats for system-to-system data and logs. Use readable formats for people. Before publishing a scenario, test the complete value at a timezone boundary, around midnight, and with single-digit months or days.
How date and time formatting works in Make.com
Make.com stores or receives a datetime value, then formats that value according to a pattern. The pattern is a sequence of tokens and ordinary characters. Tokens represent parts of a date or time, such as the year, month, day, hour, minute, or timezone offset.
In a scenario, formatting commonly happens when you use the formatDate function, map a datetime into a text field, build an email or notification, or prepare a value for another application. The exact field and function options depend on the module, but the design question is the same: is this value intended for a machine, a person, or both?
Choose a date format according to the next decision the value must support, not according to how the source application happens to display it.
Core Make.com date tokens
Make.com datetime tokens are case-sensitive. A capital letter and a lowercase letter may represent different parts of the value, so copy patterns carefully and test the result in the scenario output.
Year and month tokens
- YYYY represents a four-digit year, such as
2026. - YY represents a two-digit year, such as
26. - MMMM represents the full month name, such as
October. - MMM represents an abbreviated month name, such as
Oct. - MM represents a zero-padded month number, such as
10. - M represents a month number without padding, such as
10or1.
Use YYYY rather than YY for records, exports, filenames, and integration payloads. Two-digit years create unnecessary ambiguity and can make historical data harder to interpret.
Day tokens
- DD represents a zero-padded day of the month, such as
07. - D represents a day of the month without padding, such as
7. - dddd represents the full day name, such as
Wednesday. - ddd represents an abbreviated day name, such as
Wed.
Day names are useful in human-facing messages, but they are usually unnecessary in system fields. A downstream system can calculate the weekday from a valid date, while a weekday written into a payload can become misleading if the date is later changed without updating the text.
Time tokens and precision
Hours, minutes, and seconds
- HH represents a zero-padded 24-hour value from
00to23. - H represents a 24-hour value without padding.
- hh represents a zero-padded 12-hour value from
01to12. - h represents a 12-hour value without padding.
- mm represents zero-padded minutes.
- m represents minutes without padding.
- ss represents zero-padded seconds.
- s represents seconds without padding.
Use 24-hour time for logs, API values, operational dashboards, and data exchanged between systems. Use 12-hour time only when the recipient expects it, and include the appropriate AM or PM indicator so values such as 08:30 are not ambiguous.
Fractional seconds and timezone output
- SSS can be used when millisecond precision is needed and is supported by the relevant Make.com formatting context.
- A and a are commonly used for uppercase or lowercase AM and PM indicators.
- Z or ZZ can represent a timezone offset where supported by the formatting context.
Do not add milliseconds merely because they are available. Precision should reflect the business need. If no process distinguishes two events that happen within the same second, milliseconds add noise rather than useful information.
A timestamp is reliable only when its date, time, and timezone assumptions are clear. Formatting a local time as if it were UTC changes the meaning of the record even when the visible pattern looks correct.
Practical Make.com date and time formats
The following patterns illustrate common choices. Confirm the output in your own scenario because the source value, account settings, module behavior, and timezone parameter all affect the final result.
Sortable date and time
Use this for logs, internal records, filenames, and values that need consistent ordering:
YYYY-MM-DD HH:mm:ss
An example output is 2026-10-01 23:07:30. This is readable and sorts predictably when all values use the same timezone convention.
ISO-style timestamp for integrations
For APIs and systems that expect an ISO-style value, use:
YYYY-MM-DD[T]HH:mm:ssZ
This produces a structure such as 2026-10-01T23:07:30+02:00 when the timezone offset is included by the formatting context. Do not append a literal Z to a local time unless the value genuinely represents UTC. The letter Z is commonly understood to mean UTC, so using it as decoration can create a two-hour or more discrepancy.
Human-readable notification
For an email, task update, or chat message, use a pattern such as:
dddd, MMMM D, YYYY at h:mm A
An example output is Thursday, October 1, 2026 at 11:07 PM. This is easier for people to scan, but it is not a good replacement for a structured datetime field.
Compact date for a report
For a report column where the time is not relevant:
YYYY-MM-DD
Keep the original datetime in a separate field if users may later need to investigate ordering, response time, or timezone differences.
A reliable sequence for formatting dates in a scenario
Common datetime problems in Make.com
Confusing formatting with timezone conversion
Formatting changes how a value is represented. It does not necessarily convert the value to the recipient’s timezone. A scenario that sends a meeting reminder should first establish which timezone the meeting belongs to, then format the converted value for the recipient.
Using an ambiguous date pattern
Patterns such as 03/04/2026 can be interpreted as March 4 or April 3 depending on regional convention. Use YYYY-MM-DD for system data, or spell out the month in user-facing content.
Mixing date-only and datetime fields
A due date of October 1 is not necessarily midnight on October 1. Treating a date-only value as a datetime can shift the displayed date when a timezone conversion is applied. Decide whether the field represents a calendar date or an instant in time.
Using formatted text for later calculations
Keep the original datetime available for comparisons, filters, delays, and calculations. A display string is a poor substitute for the source value because it may omit seconds, timezone information, or a consistent ordering structure.
Testing only the happy path
A pattern can appear correct when tested with a value such as October 15 at midday and fail for January 3 at midnight. Boundary testing is part of the workflow design, not an optional final check.
Stable and explicit
Use a consistent numeric pattern, preserve timezone meaning, and keep the value suitable for sorting, filtering, parsing, and reporting.
Readable and contextual
Use familiar language, include the relevant timezone when needed, and avoid forcing users to interpret an unexplained numeric string.
Example: scheduling a customer reminder
Imagine a scenario that receives a meeting time from a CRM, creates a task, and sends a reminder by email. The workflow should not immediately format the CRM value into a sentence. First, it should confirm whether the source stores UTC, an offset, or a local time. Next, it should decide which timezone the customer should see. Only then should it create a display value such as Thursday, October 1, 2026 at 11:07 PM.
The task record can retain a structured timestamp such as 2026-10-01T23:07:30+02:00, while the email uses a friendly sentence. This separation makes the workflow easier to audit and prevents a presentation choice from becoming the system’s only record of the event.
A formatted date should be treated as an interface for a specific consumer, not as the canonical record of time.
Operational checklist for Make.com datetime workflows
- Confirm whether the source contains a timezone or offset.
- Decide whether the field represents a date, a local time, or a precise instant.
- Use uppercase and lowercase tokens exactly as required by the formatting context.
- Prefer four-digit years and zero-padded numeric values for system data.
- Do not label a local value as UTC unless it has actually been converted to UTC.
- Keep a structured source value separate from a human-readable display value.
- Test midnight, month changes, single-digit values, and relevant daylight-saving transitions.
- Document the convention if multiple scenarios exchange the same datetime field.
Designing the surrounding automation
Date formatting is often a symptom of a wider integration decision. If several scenarios format the same field differently, the issue is not solved by adding another token. Define the business meaning, ownership, timezone convention, and output contract once, then apply that decision consistently across the workflow.
That process-first approach also makes it easier to decide where Make.com should transform data and where the source system should remain authoritative. ConsultEvo helps businesses design connected systems, automation, CRM workflows, and reporting around clear operational requirements. See the systems, automation, CRM and AI implementation services for broader workflow support, or review examples of connected automation, CRM and operations systems.
Frequently asked questions
What is the safest date format for data exchanged between systems in Make.com?
Use a consistent, sortable format such as YYYY-MM-DD for dates or an ISO-style datetime that preserves the timezone or UTC meaning. Confirm the receiving system's expected format before publishing the scenario.
Does formatting a date in Make.com change its timezone?
Formatting controls the output representation. It does not automatically make every source value correct for the recipient's timezone. Confirm the source timezone and perform any required conversion before formatting the final display value.
Why should I use YYYY instead of YY in Make.com?
A four-digit year is unambiguous and works better for records, exports, filenames, integrations, and long-lived reporting. Two-digit years can be interpreted inconsistently and are harder to audit.
Should I use a human-readable date in an API payload?
Usually not. APIs and downstream systems generally benefit from a stable numeric datetime with explicit timezone meaning. Create a separate readable version for emails, messages, or user interfaces.
Why does a Make.com date appear one day earlier or later?
The source may be a date-only value that was treated as a datetime, or a timezone conversion may have crossed midnight. Inspect the original value, timezone, conversion step, and final formatting pattern.
Need a reliable date and time workflow?
If inconsistent timestamps, timezone assumptions, or integration formats are creating operational problems, ConsultEvo can help define the process and implement a dependable automation design.
