Best Practice for Storing and Displaying LocalDateTime When AEP Only Accepts UTC, Store Dual Fields or Use Conversion Functions? | Community
Skip to main content
Level 1
April 29, 2026
Question

Best Practice for Storing and Displaying LocalDateTime When AEP Only Accepts UTC, Store Dual Fields or Use Conversion Functions?

  • April 29, 2026
  • 0 replies
  • 8 views

Hi Community,

I'm looking for guidance on handling datetime values in Adobe Experience Platform where the source data is in local datetime but AEP's datetime datatype only stores values in UTC.

The scenario:

We ingest event data that includes timestamps originally in local datetime. Since AEP schemas require the datetime datatype to be in UTC format, the local time context is lost upon ingestion.

However, when we use this data downstream for example, in personalization templates or email rendering we need to display the datetime back in the original local datetime format for the end user.

My questions:

  1. Dual storage approach — Is it a recommended practice to store both a string field (preserving the original local datetime as-is) and a datetime field (in UTC) in the schema? This way, the string field can be used for display purposes and the datetime field for any time-based logic or segmentation. 

  2. Conversion functions — Are there any built-in helper functions that can convert a UTC datetime value back to a specific local datetime at the point of rendering? If so, how would that work — would we also need to store the timezone/offset alongside the UTC value?

  3. Timezone handling — If conversion functions exist, do they require a separate field storing the timezone identifier (e.g., America/Chicago+05:30) to perform the conversion from UTC back to local time?

Would appreciate any best practices or patterns the community has used to solve this. Thanks in advance!