Date Field with Flatdate Picker Widget Changing Date Value on Edit

Aditi Saraf → made their first commit to this issue’s fork.

I will work on this

I got this issue fixed by changing the user ( who will create the content ) time Zone to the country standard time Zone .

Suppose A user who is creating content has time Zone UTC then time will not change on edit content page .

Hello @aditi Saraf ,
Thankyou for the response ,
I attempted to change the time zone, but it didn't work for me. Have you added the custom format m-d-Y to the date picker widget? Could you please explain the steps you followed?

NO UPDATES ON THIS?

Hi!

Try to keep the date format at the default.

To change the date format displayed to the user, the Aleternative Format should be used. (See image)

Thanks for the response , is there any way if we can change the default format to our own format to pick date.
when i do so all the days are set to be disabled.

Can you try the latest version? There was an issue with saving the widget.

Yes, I tried the latest version. Whenever I change the input date format, it automatically sets all the days to disabled, which prevents me from picking a date when creating content.

Are you absolutely sure that you are using the latest 2.0.9 version and cleared the drupal cache?

Hi
Please try the above patch

I seem to have the same issue. When I set a non-default date format, then when I edit the node the date changes to what seems like a random value. For example, (using the format "m/d/Y H:i K") a date of 18 December 2023 appears on the edit form as 03 August 2024 - time 00:00. If I save the edited form, the incorrect date is saved, which can be a real problem because it's unexpected. If I edit the date using the widget, the correct date (the one I selected) is saved. So the problem is where the widget is receiving the saved value, not where it sets the selected value.

With a little experimenting, it seems that it works with the Y format code in the first position. Trying the code "F j, Y H:i K" the date becomes "2023-12-18 18:30:00 America/New_York" which of course makes no sense.

It's good that it seems to work with the default format, but it would be great to be able to use a different format.

Hi @Peter Pulsifer,

can you please try above patch once.

Thank you

Hi, @adityarawat_ln,

That worked for me! Thanks for your assistance.

As I cannot reproduce the issue when the alternative input format is used.
So with settings:
Alternative input format: F j, Y H:i K
Date format: Y-m-d H:i

I will have to set the issue to postponed.

Feel free to reopen the issue if someone can reproduce the issue with the recommended settings.

I am tempted to change the status to "Outdated" as it really seems fixed in version 3.0 but .

If an alternative input format is used, the issue still occurs. If you also set the Date format to "Y-m-d", then the issue is fixed.
I guessed that much from your last comment and tried it and it worked.

So, do we require a code change or should we just add it to the documentation?

I think it is just that the default Date format should only be changed in rare circumstances because it is linked to data storage.
For most users only the alternative input is needed.

Maybe what we could do is to hide the Date Format option by default.

In my case the date format for the storage is Y-m-d (default date field) and we only required d/m/Y for display when editing the node.
If we only use "Alternative input format", the issue exists. If I also set "Date format" to "Y-m-d" the issue is fixed.
So, hiding the "Date format" by itself is not the solution; unless we also set the value behind the date format as "Y-m-d" by default.

I see what is wrong.

The default Date Format is Y-m-d H:i, but when the site's timezone is not set to UTC, then that format can cause issues when saving the date, and so it saves an earlier time.

However Y-m-d works fine, which is a good workaround in that case.

Then indeed there is an issue here.

However this seems to only be an issue when the field is a date field, and works fine when date and time is selected.

So likely what we need to do in the code is to detect when it is a date only field, and ignore any time related parts.

I improved the kernel tests, and fixed the issue at the storage.

Let me know if this works better.

Automatically closed - issue fixed for 2 weeks with no activity.