Global Segment Evaluation scheduling time in EST

Hello @pushkarcse , 

I agree with you—it would definitely be more user-friendly if Adobe Experience Platform supported automatic time updates during Daylight Saving Time (DST).

However, from what I've seen, this is not easy to implement in AEP due to its architectural design. To understand why this feature isn't supported, it's important to understand how AEP handles data. Adobe has opted to keep everything in UTC for consistency and simplicity across its global architecture.

All the metadata related to configurations, such as scheduling, is stored in a NoSQL database. I believe this is Azure Cosmos DB.

In other applications that use SQL databases, such as MS SQL Server, automatic Daylight Saving Time handling is managed directly by the database itself. MS SQL has built-in support for time zones and DST.

But since AEP is based on Azure Cosmos DB, which doesn't support automatic time zone or DST adjustments, Adobe decided to store everything in UTC to avoid these complexities.

Here's a quick comparison:

MS SQL Server:

• Time Zone-Aware Datatypes: MS SQL supports the DATETIMEOFFSET datatype, which stores both the date/time and the time zone offset.
  • Example: 2024-11-04 10:00:00 -05:00 (this includes both the date/time and the offset from UTC).
• Automatic DST Handling: When using DATETIMEOFFSET, MS SQL allows you to store and retrieve time zone-aware data, and it adjusts for DST automatically during queries.
• Conversions: MS SQL has functions like SWITCHOFFSET and AT TIME ZONE that allow you to convert between different time zones and handle DST adjustments internally.

Azure Cosmos DB:

• No Native Time Zone Support: Cosmos DB stores timestamps in UTC by default and doesn’t have built-in support for DATETIMEOFFSET, like MS SQL. Timestamps are usually stored as ISO 8601 formatted strings (e.g., "2024-11-04T10:00:00Z"), which represent UTC time.
• Any time zone conversion or DST handling must be done in the application layer, not the database.

I hope this helps clarify why AEP handles time this way.

Best regards,
Parvesh

Hi @parvesh_parmar ,

Thank you for the quick response. I understand that Adobe is using Azure Cosmos DB and hence scheduling is taking UTC timezone . As a downstream user , we would like to have timezone based scheduling so that manual intervention is skipped during DST.

For the comment : "Any time zone conversion or DST handling must be done in the application layer, not the database." 

I would like to have some standard suggestion that I can integrate with our app in order to overcome the manual rescheduling during DST.

Thanks And Regards

Pushkar Kumar

Hello @pushkarcse , 

As a workaround, you could develop an application on a cloud platform, such as an Azure Function, which will call the scheduling API whenever there is a change in the timing. This application would update the UTC time for active jobs accordingly.

It's not the ideal solution, but it could be effective.

Hope this helps.

Best regards,
Parvesh