Date/time picker stores the timezone in a separate XML element

[sumerjabri]

Feature Request

Is your feature request related to a problem? Please describe.

Having two separate XML elements emitted by a single control is questionable. Additionally, we need clarity as to the purpose documented. The timezone is used for:

• To render in that timezone based on an author's choice
• To author clearly that the selected timezone is what the author sees

Describe the solution you'd like

Consider putting the timezone as an attribute to the date/time that's in zulu. This would have to be a new form-control that supersedes the old control.

Describe alternatives you've considered

{{A clear and concise description of any alternative solutions or features you've considered.}}

[sumerjabri]

Related to Form Engine 2

[tfield]

With the datetime control already listing the time zone (currently zulu) it is confusing from a data management perspective to also list a second attached field for time zone.

If the intent is to provide the author with a preferred render time zone (distinct from their browser's current time zone) in the editorial UI, then that information could be saved as a user preference either in a db or in local storage. It is not appropriate to store author desktop preferences in the content itself.

If the intent is to influence how the field is rendered to visitors, then an independewnt field can be added to flag that - but it can be left to the developer to select the name of that field, rather than have the cms bind it to the date field. In other words, it feels beyond the scope of the CMS to store that information as a built-in field. The use cases where the author would need to specify the render time zone to override the visitor's browser time zone represent a small (but realistic) subset of datetime use cases, and the implementation should reflect this.