Changing Datetime Format to MM‑DD‑YYYY in AEP Data Prep

​@MahimaUpNo, you can't save datetime fields in AEP in the format MM-DD-YYYY HH:mm:ss. AEP only allows the ISO 8601 format for datetime fields. That is, YYYY-MM-DDTHH:mm:ssZ, 2026-04-10T14:23:56Z 

Why: AEP uses XDM standards, and for consistency across systems, datetime fields are stored as timestamps instead of strings. which is needed for event ordering, profile stitching, time-based queries, and segmentation. If you change the time format, these features will stop working. 

You can use DataPrep to parse the incoming "string" timestamp (your source) and turn it into a proper XDM datetime.

Data Prep Function: 

to_timestamp(your_field, "yyyy-MM-dd HH:mm:ss")

To add on top of ​@Asheesh_Pandey ‘s comment: you should not be worried about YYYY-MM-DD vs MM-DD-YYYY as long as there is no loss of data, also former one is standard iso format (iso 8601).

If you have any specific data wise requirement to show up in dashboard, those can be managed by formatting  function at the dashboard end.

Thank you!

Hi ​@MahimaUp 

• No – you cannot store an XDM dateTime in MM‑DD‑YYYY HH:mm:ss format in AEP. XDM dateTime is always stored as ISO‑8601 like 2026-04-10T14:23:56.000Z (and XDM date as 2026-04-10).
• Data Prep's format patterns are only for parsing incoming strings, not for changing the internal storage format.
• If you want MM‑DD‑YYYY HH:mm:ss for display, treat it as a presentation concern (Query Service, AJO templates, downstream systems) or as an additional string field, not as the primary dateTime.

1. Can AEP store MM‑DD‑YYYY HH:mm:ss in a dateTime field?

Technically: no.

For XDM:

• date fields must look like e.g. 2026-04-10
• dateTime fields must look like e.g. 2026-04-10T14:23:56.000Z

These are enforced by the XDM field constraints and ISO‑8601 rules; AEP will validate and normalize to this format regardless of how the source string looked when you ingested it https://experienceleague.adobe.com/en/docs/experience-platform/xdm/schema/field-constraints

So you cannot have an XDM dateTime that is stored as 04-10-2026 14:23:56. You can only store that as a plain string field.

2. What does Data Prep's date format actually do?

When you use something like:  date(source.timestamp, "yyyy-MM-dd HH:mm:ss") 

in Data Prep:

• The second argument ("yyyy-MM-dd HH:mm:ss") tells Data Prep how to read the incoming string.
• The output is then converted into an XDM‑compatible date or datetime

So yes: the format is strictly for parsing at ingestion, not for choosing a different stored pattern.

https://experienceleague.adobe.com/en/docs/experience-platform/data-prep/data-handling

https://experienceleague.adobe.com/en/docs/experience-platform/data-prep/functions#date-and-time

3. Given your source: 2026-04-10 14:23:56

and requirement to use it inside AEP as a proper timestamp while still being able to show MM‑DD‑YYYY HH:mm:ss, do this:

a. Keep the canonical field as XDM dateTime

In your schema, define the target as dateTime.

In Data Prep mapping, parse the source string to XDM: date(source.timestamp, "yyyy-MM-dd HH:mm:ss")

This will store something like: 2026-04-10T14:23:56.000Z

in the dataset/profile – this is what you should use for segmentation, profile logic, time comparisons, TTL, etc.

b. If you truly insist on MM‑DD‑YYYY inside the dataset

You can skip dateTime entirely and define the field as string, ingesting it exactly as: 04-10-2026 14:23:56

But then:

• You lose all native date/time semantics in AEP (no proper comparisons, rolling windows, etc.).
• You'll be forced to treat it as text everywhere.

So the recommended pattern is:

Correct time logic, segmentation, profile behavior  => XDM dateTime field, parsed via date(...)

Human‑friendly MM‑DD‑YYYY HH:mm:ss display => Format at read‑time (Query Service / app) or store in an extra string field