Fix date field being parsed with a timezone

[derrickmehaffy]

Signed-off-by: Derrick Mehaffy derrickmehaffy@gmail.com

What does it do?

Stops using the built in Javascript date which reads the systems timezone by replacing new Date() with the date-fns function parseISO see it's docs here

Why is it needed?

if the string value passed from upstream in Strapi is 2021-04-14:

date-fns function

const cast = parseISO(value);
// returns: 2021-04-14T07:00:00.000Z

javascript native function

const cast = new Date(value);
const castString = cast.toString();
// returns: Tue Apr 13 2021 17:00:00 GMT-0700 (Mountain Standard Time)

The problem is that the built in Javascript Date() will use the local systems timezone, and instead the date-fns has the ability to just parse the raw date string and not pass in the system timezone.

How to test it?

Your system must be set to a timezone that is +/- GMT by at least 1 hour

1. Create a project
2. Create a model with a date field
3. Add a new date via any means
4. See date doesn't move backwards or forwards

Related issue(s)/PR(s)

fixes #9576

[Edit]

I (@petersg83 ) took over this PR. It appears the problem is quite complex and larger than this specific issue. We need to refactor all the way we handle dates (disable timezone in pg for instance) and it would be more of a breaking change than a bug fix. So we won't fix everything now but it will be fixed in V4 (should come in beta ~summer and released before the end of the year).

However, I wrote a small change in the admin. It may fix #9576, not sure.

[codecov]

Codecov Report

Merging #10033 (01f5fa6) into master (c930b24) will not change coverage.
The diff coverage is n/a.

❗ Current head 01f5fa6 differs from pull request most recent head dd4ad60. Consider uploading reports for the commit dd4ad60 to get more accurate results

@@           Coverage Diff           @@
##           master   #10033   +/-   ##
=======================================
  Coverage   60.06%   60.06%           
=======================================
  Files         183      183           
  Lines        5702     5702           
  Branches     1077     1077           
=======================================
  Hits         3425     3425           
  Misses       1817     1817           
  Partials      460      460           

Flag	Coverage Δ
front	∅ <ø> (∅)
unit	60.06% <ø> (ø)

Flags with carried forward coverage won't be shown. Click here to find out more.

---

Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update c930b24...dd4ad60. Read the comment docs.

[alexandrebodin]

why isn't it necesssary on the other types like datetime ?

Seems like the test are breaking now

[derrickmehaffy]

why isn't it necesssary on the other types like datetime ?

Seems like the test are breaking now

Honestly I have no idea, it's extremely difficult for me to track down how or why the local system timezone is being pulled in. The backend should -only- function in UTC. The Admin panel should be doing the time conversion but the date field specifically is the only field that shouldn't even be working with time but the default JS Date() generates a date with a time (and timezone).

[petersg83]

In your example, why does it return 2021-04-14T07:00:00.000Z (with hours to 7)?
Here is what I have on my computer :

I'm thinking that the best would be that the front sends a YYYY-MM-DD string. At the moment the front sends a datetime with a timezone (see bellow). And no matter how we parse it, we won't be able to know what date was displayed to the user when they save.

[derrickmehaffy]

In your example, why does it return 2021-04-14T07:00:00.000Z (with hours to 7)?
Here is what I have on my computer :

I'm thinking that the best would be that the front sends a YYYY-MM-DD string. At the moment the front sends a datetime with a timezone (see bellow). And no matter how we parse it, we won't be able to know what date was displayed to the user when they save.

That is the issue @petersg83 is we are using parsing functions which is converting it to a datetime (with TZ information).

Realistically we shouldn't be parsing the date other than maybe to change formats (US uses mm/dd/year / Europe uses dd/mm/year / programming typically uses year/mm/dd).

What we need is for the frontend to only send UTC/GMT and parse it on the server like that without reading the system timezone, but we also need to customize this in case some users for whatever reason change the database timezone (which can be done on SQL databases)

[petersg83]

@soupette I only changed the input data, not the filter. I think it's good enough for the moment, I don't have time to dig if there is a problem with how we handle the dates with the filter