> ## Documentation Index
> Fetch the complete documentation index at: https://docs.alumio.com/llms.txt
> Use this file to discover all available pages before exploring further.
# Date Formats
Example Transformer: Common Date Formats
Reference walkthrough of the Common date formats example configuration: relative date calculations and standard date/time output formats for transformer chains.
## Overview
This page documents an importable Data Integrator example configuration (`register.configuration.json`) named `[Example] — Common date formats` (identifier `example-common-date-formats`). It is not built to solve one specific integration; it is a reference snippet consultants can copy into a real flow and adapt.
The configuration is a plain `list-transformer` object, so it can be imported directly into a Data Integrator environment and inspected transformer-by-transformer in the flow builder.
The example is a single `data` transformer with two `value-setter` blocks: one that evaluates relative date expressions, and one that reformats the current moment into several standard formats.
The relative expressions (`yesterday`, `next monday`, `first day of this month`, …) and the `toFormat` tokens (`Y`, `m`, `d`, `H`, `i`, `s`, `c`, `r`, `U`, `W`, `P`) follow PHP's `strtotime()` phrasing and `date()` format characters, which is the convention the `format-date` mapper is built on.
## Relative date expressions
Example outputs below assume a flow running on **Monday, 7 September 2026, 14:32 (Europe/Amsterdam, UTC+2)**.
| Key | Input expression | `toFormat` | Example output |
| --------------------------------- | ------------------------- | ------------- | --------------------- |
| `yesterday` | `yesterday` | `Y-m-d H:i:s` | `2026-09-06 00:00:00` |
| `tomorrow` | `tomorrow` | `Y-m-d H:i:s` | `2026-09-08 00:00:00` |
| `7_days_from_now` | `+7 days` | `Y-m-d` | `2026-09-14` |
| `30_days_ago` | `-30 days` | `Y-m-d` | `2026-08-08` |
| `first_day_of_the_current_month` | `first day of this month` | `Y-m-d` | `2026-09-01` |
| `last_day_of_the_current_month` | `last day of this month` | `Y-m-d` | `2026-09-30` |
| `first_day_of_the_previous_month` | `first day of last month` | `Y-m-d` | `2026-08-01` |
| `first_day_of_the_next_month` | `first day of next month` | `Y-m-d` | `2026-10-01` |
| `next_monday` | `next monday` | `Y-m-d` | `2026-09-14` |
`yesterday` and `tomorrow` reset the time portion to `00:00:00`, while `+7 days` / `-30 days` preserve the original time of day. `next monday`, evaluated from a Monday, jumps a full week ahead rather than staying on the same day, this is standard `strtotime()` behavior and easy to trip over when a flow runs on a Monday.
The block also contains a `today_with_timezone` entry with `toFormat` set to `Y-m-d\TH:i:sP\` (note the trailing backslash). That trailing backslash is a harmless leftover, PHP-style date formatting ignores a dangling escape, so the output is identical to the ISO-8601 `c` format shown below: `2026-09-07T14:32:00+02:00`. If reusing this pattern, drop the trailing backslash (`Y-m-d\TH:i:sP`) for clarity.
## Well-known date/time formats
The second block formats "now" (an empty input value) into several standard representations:
| Key | `toFormat` | Format | Example output |
| ------------------------ | ---------------- | ---------------------------------- | --------------------------------- |
| `ISO_8601_in_UTC` | `Y-m-d\TH:i:s\Z` | ISO-8601, literal `Z` suffix | `2026-09-07T14:32:00Z` |
| `ISO_8601_with_timezone` | `c` | ISO-8601 with real UTC offset | `2026-09-07T14:32:00+02:00` |
| `RFC_2822_email_format` | `r` | RFC 2822 (email/HTTP header style) | `Mon, 07 Sep 2026 14:32:00 +0200` |
| `unix_timestamp` | `U` | Unix timestamp (seconds) | `1788784320` |
| `week_number` | `W` | ISO-8601 week number | `37` |
`ISO_8601_in_UTC` appends a **literal** `Z`, it does not convert the value to UTC first. Use it only when the underlying date is already in UTC. When the value is in a local timezone (as in this example, Europe/Amsterdam), prefer `ISO_8601_with_timezone` (`c`), which encodes the real offset instead of a false `Z`.
## Format token quick reference
| Token | Meaning |
| ---------- | -------------------------------------------------------- |
| `Y` | 4-digit year |
| `m` | 2-digit month |
| `d` | 2-digit day of month |
| `H` | 2-digit hour, 24h |
| `i` | 2-digit minute |
| `s` | 2-digit second |
| `P` | UTC offset with colon, e.g. `+02:00` |
| `\T`, `\Z` | Escaped literal characters `T` / `Z` (not format tokens) |
| `c` | Shorthand for full ISO-8601 (`Y-m-d\TH:i:sP`) |
| `r` | Shorthand for RFC 2822 |
| `U` | Unix timestamp (seconds since epoch) |
| `W` | ISO-8601 week number |
## Transformer prototypes used
| Prototype | Role |
| -------------- | ------------------------------------------------------------------------- |
| `data` | Applies a set of transformers to the current record |
| `value-setter` | Writes one or more computed values onto fields, via optional `mappers` |
| `format-date` | Mapper: parses a date expression and renders it with a `toFormat` pattern |
The example is self-contained enough to import as-is, run once, and inspect the output per field, which is the fastest way to confirm a date format behaves the way a ticket or requirement expects before wiring it into a production flow.