The unix operation turns a date into a Unix timestamp, the number of seconds since 1 January 1970.
Use it when an API expects a number rather than a written date, and when you want to compare two dates by size rather than by text.
How it works
Give it a date and you get a number back.
2024-12-25 → 1735084800
2025-03-01 12:00 → 1740830400
01/01/1970 → 0
The timestamp is always counted in UTC.
When it cannot read the date
The field keeps its original value. Nothing is logged and no error is raised, so a date the operation could not understand travels on to the advertiser exactly as it arrived.
That is worth planning for, because the failure looks like nothing happened. If the advertiser expects a number and receives 25.12.2024, they will reject the lead and the reason will not mention dates at all.
Put a condition on the step, or check the value afterwards, rather than assuming the conversion worked.
Formats it understands
Anything written the international way is safe: 2024-12-25 or 2024-12-25 14:30:00.
Formats with slashes are read the American way, so 01/02/2025 is the first of February, not the second of January. If your dates arrive in a local format, reformat them first with format-date rather than hoping they are read correctly.
A date written as 25.12.2024 is not understood at all and comes back unchanged.
Working with other date operations
The three date operations are built to be chained:
- modify-date shifts a date forwards or backwards
- format-date writes it a different way
- unix turns it into a number
Shift first, then convert. A step that adds thirty days and a step that turns the result into a timestamp is the usual way to send an expiry date as a number.
Settings
The operation takes no parameter. Set the source and the condition, choose unix, and there is nothing else to fill in.
Reference
Dates are read with PHP’s strtotime. See PHP: strtotime for the full list of formats it accepts.

