Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

DateTimeInput changed output format without documentation in version 5.3.3 #10375

Open
starkriedesel opened this issue Nov 22, 2024 · 2 comments

Comments

@starkriedesel
Copy link

What you were expecting:
Prior to version 5.3.3 the DateTimeInput component would produce a date time string with the timezone due to the default parse function:

const parseDateTime = (value: string) =>
    value ? new Date(value) : value === '' ? null : value;

So in version 5.3.2 the DateTimeInput would send a JSON payload with a value like 2024-11-20T14:50:00.000Z. Notice that this is UTC regardless of the local timezone of the computer. This is ideal since the serve receiving the payload will not necessarily be in the same timezone as the client.

What happened instead:

However after #10335 was merged in 5.3.3 the default parse function was removed. Now the behavior is to send a timezone-less local date time leaving the server unable to determine the desired UTC time. For example the above value is sent as 2024-11-20T08:50 which cannot be parsed by the server universally.

This change was not described in the above PR and specifically was altered in an innocuous "simplify code" commit.

While I can understand that modifying user chosen time to UTC is not always desirable it seems like a significant change that was completely undocumented as part of the change logs and not totally clear why that change would be made as part of a fix for #10335

Steps to reproduce:
I'm currently using a SimpleForm with a DateTimeInput. On versions 5.3.2 and before the parsed value is a javascript Date object which ends up transformed into an ISO String by default. Example: 2024-11-20T14:50:00.000Z

<DateTimeInput source="myDateField" />

On versions 5.3.3 and later this string is no longer an ISO UTC string and is instead a local time. Example: 2024-11-20T08:50

Related code:
See above

Other information:

On a related note, your documentation for producing an ISO string is incorrect. It states that the parse function should be as follows:

<DateTimeInput
    source="published"
    parse={(date: Date) => (date ? date.toISOString() : null)}
/>

however the parse function takes a string not a Date. The correct version would be:

<DateTimeInput
    source="published"
    parse={(value: string) => (value ? new Date(value).toISOString() : null)}
/>

Environment

  • React-admin version: 5.3.3
  • Last version that did not exhibit the issue (if applicable): 5.3.2
  • React version: 18.3.1
  • Browser: Chrome
  • Stack trace (in case of a JS error): n/a
@slax57
Copy link
Contributor

slax57 commented Nov 25, 2024

Why did you self-close your issue? It seems to me your point is valid.

I had a look, and indeed it seems that v5.3.3 includes an undocumented change in the type (and timezone) of the DateTimeInput return value:
v5.3.2: published value in form: "2024-11-25T08:50:00.000Z" (object)
v5.3.3: published value in form: "2024-11-25T09:50" (string)

Regarding the documentation issue, the section you mention actually applies to the Material UI (i.e. Enterprise) version of the DateTimeInput component, not the community one.
However, the Usage section would have to be updated if we are to keep that change.

Hence, I'm reopening this issue.

@slax57 slax57 reopened this Nov 25, 2024
@starkriedesel
Copy link
Author

Why did you self-close your issue? It seems to me your point is valid.

Oh that's great. I actually self closed because when I went to revert to an older version the tests were still failing and so I felt I may have misunderstood the code. I'm not very familiar with react, I just have to maintain some of our company's code :)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants