Handling (or ignoring) multiple time zones in date & time fields in Content Fragment models

[tomek-niedzwiedz]

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 &amp; 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:

1. 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.
2. 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

1. force the field to store values as local dates, or
2. 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 had luck either changing the format of the persisted date or configuring the field to be more readable (possibly via overlaying it)?

Penny for your thoughts,

Tomek

[gkalyan]

@tomek-niedzwiedz 

With built in "Date" mandating ISO, you can try creating custom Date field

with valueFormat="YYYY-MM-DD HH:mm" to avoid timezone

[h_kataria]

Interesting use case, could you elaborate more on 

1. 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).
   
   How are you reading the values ? Essentially it is a property of the content fragment which you should be able retrieve and manipulate as per your requirement. If possible could you send me a package to try this out  ? 

[tomasz-niedzwiedz]

When I read the values in my code, I just drop the time zone, which works fine for this use case. Here's the utility function that does this. The Calendar object is read from the JCR.

public static LocalDate convertToLocalDate(Calendar calendar) {
  if (calendar == null) {
    return null;
  }
  return LocalDate.ofInstant(calendar.toInstant(), calendar.getTimeZone().toZoneId());
}

So the way my application displays the dates is fully under my control.

It's in the Content Fragment Editor that I can't control the way it's displayed (unless I override the field).

Let's say a user from a specific time zone, say UTC, creates a Content Fragment with the date 11:00 am.

1. On pages that use my custom component, everyone will see 11:00 am, regardless of the time zone that they're in.

2. On Author, users from the UTC time zone will see the same date as the one displayed on-page, but users from different time zones will see the date adjusted, as per their own time zone, which will be different from the one displayed on-page. This can be very confusing.

I don't have a package I can share, as this is proprietary code, but you should be able to reproduce this just by creating a Content Fragment Model with a DateTime field and saving/viewing it a few times from different time zones.

For now, it seems the answer is to override the field, but it would be a handy improvement to make this behaviour configurable OOTB, or display the time zone somewhere in the UI, or maybe just the fact that the date is localized.

[h_kataria · Accepted solution]

ok, so in that scenario if adding time zone information could help then you can try adjusting the displayedFormat. 

Timezone1 :

Timezone2:

[kautuk_sahni]

@tomek-niedzwiedz Did you find the suggestion helpful? Please let us know if you require more information. Otherwise, please mark the answer as correct for posterity. If you've discovered a solution yourself, we would appreciate it if you could share it with the community. Thank you!