Cross-posted from https://experienceleaguecommunities.adobe.com/t5/adobe-experience-manager-assets/handling-or-ignoring-multiple-time-zones-in-date-amp-time-fields/m-p/671640#M4626

I have a Content Fragment model containing date and time fields, some with a valueType of calendar/datetime, some with a valueType of time. The model represents in-person events held at specific venues. Here’s an example field definition, serialized to XML. This was created using the Content Fragment Model Editor on a local AEM instance (based on the SDK), and downloaded into our codebase with Vault:

<_x0031_709108733666
    jcr:primaryType="nt:unstructured"
    sling:resourceType="dam/cfm/models/editor/components/datatypes/datepicker"
    displayedFormat="YYYY-MM-DD HH:mm"
    emptyText="YYYY-MM-DD HH:mm"
    fieldDescription="The date on which the event begins."
    fieldLabel="Event Start Date & Time"
    listOrder="5"
    metaType="date"
    name="eventStartDateTime"
    renderReadOnly="false"
    required="on"
    showEmptyInReadOnly="true"
    type="datetime"
    valueFormat="YYYY-MM-DD[T]HH:mm:ss.000Z"
    valueType="calendar/datetime">
    <granite:data
        jcr:primaryType="nt:unstructured"
        typeHint="Date"/>
</_x0031_709108733666>

What we were looking for, when implementing this, was a way for authors to provide a date and time in a foolproof way (hence the picker and its built-in validation). The semantics of the Content Fragment are that it represents an event happenning at a specific location and that the date and time should be assumed to pertain to the local time in that location.

As we tested this a bit more thoroughly, we noticed that differnet users were seeing different times, and sometimes even different dates when looking at the same Content Fragments. This seems to be caused by a combination of two factors:

The field stores a full timestamp in the JCR, which we expected. We wanted to save those dates in the JCR using the built-in Date type, which, as far as I can tell, mandates the use of ISO 8601:2000 compliant, full timestamps.
When reading the value back from the JCR, the field appears to localize the date. The day and hour stored in the JCR is not printed verbatim. Instead, the date is adjusted, based on the difference between the time zone stored in the JCR and the local time zone of the user (based on browser, and effectively system settings).
The latter came as a surprise, and it adds a bit of a mental overhead in our use case, whereby anyone inspecting a Content Fragment, which represents an in-person event that cannot be joined remotely, needs to remember to look up the actual date and time at the location of the venue.

In my opinion, the way this information is presented can be very confusing, as the time zone is not shown anywhere and it’s not explained anywhere in the UI that the date being displayed is localized.

Is there a way to either

force the field to store values as local dates, or
have the field present this information in a way that makes it clear what time zone is used?
I’ve tried adjusting the valueFormat property on the CF Model, but that alone didn’t change the way the date is persisted in the JCR. Neither did removing the typeHint or setting it to String. As far as I can tell, the UI for the Content Fragment Model Editor doesn’t even allow me to change this, but a code-only solution could be workable. We don’t expect anyone to manually adjust those Content Fragment Models anyway.

Has anyone managed to change the format of the persisted date by modifying the JCR properties of the CF Model?
Alternatively, could the field be configured to be more readable or would this required an overlay?

Penny for your thoughts,

Tomek