Make.com Date and Time Functions: A Practical Guide to Reliable Automation

How Make.com treats date and time values

A date used in a scenario has two different roles. It can represent a point in time that a system needs to calculate or compare, or it can be a formatted piece of text intended for a person or another application. These roles should not be confused.

For example, 2026-10-05T14:30:00Z can be compared, shifted, and used in a filter. A value such as 5 October 2026 at 2:30 PM may be easier to read, but it is less suitable for calculations unless its format and timezone are unambiguous.

Before building a formula, inspect the output bundle from the module that supplies the value. Confirm whether the field is already a date, a timestamp, or text. Also check whether the source includes a timezone or relies on a default. A field labelled due date may contain a date only, while a field labelled created at may contain a complete timestamp.

The core date and time operations in Make.com

Formatting a date with formatDate

Use formatDate when a date needs to be represented in a particular pattern. Common uses include displaying a date in an email, producing a filename, sending a value to an API, or standardising a field before it is stored.

The format pattern should be chosen based on the receiving system or the person reading the value. A short date such as 05/10/2026 can be ambiguous when teams work across regions. A format such as 2026-10-05 is more predictable for data exchange, while a format such as 5 October 2026 is usually clearer in a customer-facing message.

Formatting is a presentation operation, not a correction operation. If the source date has been interpreted incorrectly, changing its appearance will not fix the underlying value.

Parsing text with parseDate

Use parseDate when a source provides a date as text and Make.com needs to understand its structure. The input pattern must describe the text accurately. If the source says 10/05/2026, you need to know whether that means 10 May or 5 October before choosing the pattern.

Parsing should happen close to the point where unstructured or external data enters the scenario. Once the value has been parsed, pass the resulting date through later modules instead of repeatedly parsing the original text.

Typical sources that may require parsing include form submissions, spreadsheet cells, webhook payloads, imported CSV data, and APIs with custom date formats.

Adding and subtracting time

Functions such as addMinutes, addHours, addDays, addMonths, and addYears are useful when a new date depends on an existing one. Examples include calculating a review date, creating a reminder window, or setting an expiry time.

The business rule should be clear before selecting the function. Adding 24 hours is not always the same business outcome as moving to the same local time on the next calendar day, especially around daylight-saving changes. Similarly, adding a month requires a decision about how end-of-month dates should behave.

For simple elapsed-time rules, use a duration such as minutes or hours. For calendar rules, define what the business means by next day, next month, or working day before implementing the calculation.

Finding the difference between dates

dateDifference can help calculate the interval between two dates. It is useful for measuring elapsed time, checking whether a response window has passed, or deciding whether a record should move into a follow-up process.

Decide whether the result should be measured in minutes, hours, days, or another unit. Also decide whether the rule is based on elapsed time or calendar time. A support rule that says respond within 24 hours is different from a rule that says respond by the next working day.

A practical sequence for date logic in a Make.com scenario

Use the following sequence when adding or reviewing date operations. It separates data interpretation from business decisions and presentation.

Timezones: the decision that affects every calculation

Timezone problems often look like formula problems. A scenario may produce a technically valid result that is wrong for the people or system using it. This happens when the source timezone, scenario timezone, account settings, and destination timezone are treated as if they were the same.

Choose a reference timezone for the workflow and document it. For integrations between systems, UTC is often a useful reference for storing or comparing timestamps, but a local timezone may be the correct basis for a business rule such as sending a reminder at 9:00 AM for a regional team.

Convert a value deliberately when it enters the scenario or when it is presented to a user. Do not rely on an invisible default if the result affects scheduling, customer communication, deadlines, or reporting.

Common failure modes and how to diagnose them

A date is displayed correctly but compares incorrectly

This usually means a formatted text value is being used in a comparison, or two values use different timezone assumptions. Compare parsed date values where possible, and format the result only after the decision has been made.

The day changes unexpectedly

A date-only value may have been interpreted as midnight in one timezone and then converted into the previous or next calendar day. Check whether the field represents a date or a timestamp and decide which timezone owns the calendar meaning.

The output is blank or produces an error

Inspect for missing values, unexpected separators, inconsistent source formats, or a format pattern that does not match the input. A scenario that receives dates from several sources may need a validation branch before parsing.

A reminder runs at the wrong local time

Check the timezone used by the source, the Make.com scenario, and the destination module. Then clarify whether the requirement is a fixed elapsed interval or a local calendar time.

Example: calculating a follow-up deadline

Consider a hypothetical sales workflow where a qualified enquiry needs a follow-up within two business days. The scenario receives a created timestamp from a CRM, checks whether the record is eligible, calculates a target deadline, and creates a task.

The first design decision is whether two business days means 48 elapsed hours or the end of the second working day in the team timezone. Those are different rules. If the team means working days, the scenario needs explicit handling for weekends, holidays, and the team timezone. If the rule is simply 48 hours, an hour-based calculation may be appropriate.

The target date should remain a date value while filters and task creation logic run. It can then be formatted for the task title or notification. This separation makes it easier to change the notification format without changing the deadline calculation.

Designing date logic as part of a reliable operating system

Date functions should support a clear workflow rather than compensate for unclear ownership or inconsistent data. If a deadline is calculated automatically, someone should own the exception when the source date is missing or the deadline cannot be met.

The same principle applies to reporting. A report showing overdue records is useful only when overdue has a defined meaning, the underlying dates are comparable, and an owner knows what action follows the report. Date logic is therefore connected to process design, data quality, and handoffs.

In a broader automation project, this may involve aligning CRM fields, workflow stages, notifications, and reporting rules before implementing the scenario. ConsultEvo’s CRM consulting work covers the structure around those decisions, including pipeline logic, ownership, and integrations.

For a wider systems implementation, the systems, CRM, automation and AI implementation services page provides context on how workflow logic can be connected across business tools. A relevant example of connected operational data is the commerce and operations intelligence platform project.

A maintainable standard for Make.com date functions

Use a small number of consistent conventions across scenarios. Name fields according to their meaning, document the reference timezone, and keep parsing and formatting close to the relevant system boundary. Avoid copying slightly different date formulas into many modules when one clearly defined value can be reused.

When a scenario depends on time, test it with realistic examples: a normal working day, a month end, a missing date, a timestamp from another region, and a value near a timezone transition. Review the execution history after each change so that the input and output can be compared directly.

Most importantly, decide what the date represents before deciding which Make.com function to use. Once the business state, owner, timezone, and expected action are clear, the technical formula is much easier to select and maintain.