[4.x]: Date field with timezone option loses date on entry save/edit

[croxton]

What happened?

Description

The day may change if the time is edited and the entry saved, presumably because the system timezone is applied to the dd/mm/yyyy part of the datetime (but not the hh:mm part).

date-timezone-bug.mov

Steps to reproduce

1. Set system timezone to EDT - New York
2. Create a date field with 'Show date and time' and 'Show Time Zone' selected
3. Add the field to an entry
4. Create an entry and set a time (e.g. 18/05/2023 2:00) with the BST - London timezone, and save
5. Reopen entry, the date is now incorrectly displayed as 17/05/2023 2:00

On subsequent edits of the entry, the selected date will regress by one day if only the time value is changed. If the field is not edited then the date remains unchanged.

Expected behavior

The field should save the date and time that the editor inputted.

Craft CMS version

4.4.11

PHP version

8

Operating system and version

OS X

Database type and version

MySQL 5.7.34

Image driver and version

No response

Installed plugins and versions

Fresh install.

[croxton]

Some extra detail: the actual date stored in the db for an entry appears to be correct (what the editor entered), the issue seems to be that when re-displayed in the entry form in the CP the date is incorrectly converted to the system timezone, which means on subsequent saves (where the date field is dirty, e.g. time was edited) the date is decremented by 1 day.

[fernakr]

I came here to submit this same bug except I was having the issue on latest Craft 3 - good to know it's also happening on 4

[fernakr]

Actually my issue is slightly different in that I have a date only field and the issue still occurs whenever the date field is edited (vs. the time being adjusted)

[croxton]

Interesting @fernakr thank you. A quick test suggests that In Craft 4 a date-only field seems to work as expected.

[brandonkelly]

Thanks for reporting! Craft 3.8.12 and 4.4.12 are out with a fix for this.

[croxton]

Hi Brandon, that has fixed the issue thank you. However, I've just noticed that when the date-with-timezone field is added as a column in the entry listing for a section, the incorrect date is shown.

'Event start date' in this screenshot is different to the actual event start date value 16/03/2023 00:00 BST, because it is incorrectly converted to the system timezone when it appears in this context:

It may also be worth noting that in Twig templates a date-with-timezone field renders with the system timezone by default, rather than the timezone the editor selected for the field:

{# Renders the date using system timezone #}
{{ entry.eventStartDate|date('F d Y') }}

It is necessary to manually get the timezone like this to render the date the editor inputted:

{# Renders the date using timezone selected for the field #}
{% set tz = entry.eventStartDate.getTimezone() %}
{{ entry.eventStartDate|date('F d Y', tz) }}

This seems a little counterintuitive so I'm not sure this is the intended behaviour?

[fernakr]

Chiming in to say that I had the same confusion regarding template output and the timezone setting - but I didn't know about the getTimezone() method so that'll definitely help me out - thanks Mark!

I haven't had a chance to try the fix on Craft 3 yet, but will circle back and confirm when I do.

[brandonkelly]

Just released Craft 3.8.13 and 4.4.13 with a fix for that element index bug. Now the date/time will use the field’s time zone, and the time zone abbreviation will be shown after it (e.g. 15/04/2023, 20:00 BST).

It is necessary to manually get the timezone like this to render the date the editor inputted:

You can pass false to that timezone argument instead, which tells Twig to leave the existing value’s time zone alone, rather than set it to the system time zone:

{{ entry.eventStartDate|date('F d Y', false) }}

or if you want to include the time + time zone abbreviation:

{{ entry.eventStartDate|date('F d Y, G:i T', false) }}

[fernakr]

Thanks @brandonkelly - that seems to have resolved the issue for me in Craft 3. Also helpful to know about passing false in the timezone argument!