Date field converting to UTC incorrectly

[codfish]

Bug report

Describe the bug

Note: I'm in NYC, so it's currently UTC-05:00.

Two issues I'm seeing here:

1. Date fields (with no time) are being decremented by a day on initial save as well as every subsequent save after that. My educated guess as to what's happening is that js Date's will assume a date string you provide is UTC and convert it to local for you:

When using a date time field it works correctly (whatever time I put in is treated like local time, and on submit its sent as the correct UTC to the api).

2. As you can see by the linked screencast below, after saving if you refresh the page or leave and come back to the form, the values of those date & time fields aren't visible. They're set but the datefield's just not showing the values.

Steps to reproduce the behavior

1. Create any content type
2. Add a date field to the content type
3. Select any date
4. Save
5. Refresh

If you're west of GMT like I am, you'll see the date get decremented by a day. You can view the network requests in dev console to see the dates being sent and received.

My scenario:

• I have a book content type
• Books have a release_date field of type date

Expected behavior

I'll start by saying the ultimate goal and my expectation is that if I save a date time, date, or time in the CMS and refresh the page, I would expect it to show me exactly what I input, regardless of how the data is stored. Currently, that's not what's happening for me.

Screenshots

https://share.getcloudapp.com/rRu0O0w5

System

• Node.js version: v14.7.0
• NPM version: 6.14.7
• Strapi version: 3.4.0
• Database: sqlite3
• Operating system: macOS

Additional context

I've worked on CMS's in the past and we've had to solve this issue one way or another depending on the scenario. One possible solution would be to tack on a timestamp WITHOUT the timezone designator. Date API will treat that as local time and won't try to convert it.

---

This may be irrelevant for this bug, however it's worth noting for anyone that stumbles on this with similar scenarios: even if you fix the issue it won't actually solve my use case, cause while it will say 12/15/2020 for NY timezone which is expected, the (proper) conversion will make it the 24th in California for instance, which is not really what I'm looking for. So in my case I can probably opt for either:

1. A datetime field and set it to 12pm or something so it's gonna be 25th in the majority of my target timezones
2. A text field where I would enter 2020-12-25 and add the T00:00:00 on the frontend when formatting the date to prevent any utc to local conversions.

[derrickmehaffy]

Confirmed on latest release (v3.4.0) and current master as of commit: 6202424

Steps to reproduce:

• Create a model with a date (date only) field
• Enter the date: 2020:12-03
• Save
• See date changed to 2020-12-02

Expected result is date remains on 2020-12-03, just dates should not be converted, only datetime.

[edardev]

Hello @derrickmehaffy and @codfish,

I have the same issue after upgrading from strapi v3.3.x to the latest v3.4.0 using PostgresDB.

I can also save an entry even if the required fields are left empty.

[derrickmehaffy]

Hello @derrickmehaffy and @codfish,

I have the same issue after upgrading from strapi v3.3.x to the latest v3.4.0 using PostgresDB.

I can also save an entry even if the required fields are left empty.

Unrelated and that action is expected if you have draft and publish enabled, you can save without the required but you can't publish.

[edardev]

@derrickmehaffy The event is "published" and the date value is saved in the Database and shows up in the API request and everything but does not show up in the admin after saved.

I will submit another issue because a required field should not be left empty, it was working just fine before the upgrade to v3.4.0.

I wish I could fix it myself and send a pull request, thank you for everything @strapi team 🚀🚀🚀

[derrickmehaffy]

Yeah please open up a new issue for that, drafts don't need the required fields but published items need to be.

[codfish]

@derrickmehaffy @EAdeveloper So I could be wrong but I'm pretty sure the values are set, NOT empty. But it's just not being displayed in the component. So that bug is just that the component isn't displaying the value properly, i don't think it's a validation issue (cause the values are set under the hood). This is separate from the conversion bug though I suppose, so if you wanted to open a ticket anyway, that would probably be best.

[derrickmehaffy]

@derrickmehaffy @EAdeveloper So I could be wrong but I'm pretty sure the values are set, NOT empty. But it's just not being displayed in the component. So that bug is just that the component isn't displaying the value properly, i don't think it's a validation issue (cause the values are set under the hood). This is separate from the conversion bug though I suppose, so if you wanted to open a ticket anyway, that would probably be best.

You are correct, they were, and that issue was fixed in v3.4.1

---

Date field being converted is still a bug.

[ImperiousEnterprise]

Still running into this bug. Is there any plans to fix this in the next release? If not, where would be a good point to start in order to fix this myself?

[wszczepaniak]

I'm on 3.6.3 and confirm the issue. Every time I create an entry with Date field using API call (using ISO format) , the date persisted is moved even by 2 days earlier.
Example : request payload : {"name": "blah blah", "start_date": "2021-06-22T21:44:48.449Z"}
persisted entity : "06.20.2021"

This happens only for Date fields. Does not happen on DateTime fields.

[marcioluis]

The conversion could use the number constructor of Date as a workaround.
new Date(2020, 0, 20)

Or add an extra blank space after the ISO date
new Date("2020-1-20 ")

[derrickmehaffy]

Still running into this bug. Is there any plans to fix this in the next release? If not, where would be a good point to start in order to fix this myself?

The source of the issue us much harder to deal with in the v3, we are looking to fix this in the v4.

[ekimv]

Hello,

In v4, Date fields have the same problem : if I put 2022-01-05, when I save, it shows then 2022-01-04...
I think the problem is that I am in French timezone (UTC+1), so when I set the date to 2022-01-05, it converts it into a datetime object with my locale timezone (so 2022-01-05T00:00:00UTC+1) which is converted in the API to UTC TZ (2022-01-04T23:00:00.000Z)
After it has been saved, the date does not change (unless I change it), because the date is sent in string format and not parsed.

Maybe for date only, the date fields should not use the locale timezone and send it with Z timezone, so '2022-01-05T00:00:00Z' to keep the correct date ?

[derrickmehaffy]

duplicate: #11509