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

Datetime Picker Frequently Shows Incorrect Time for Field::Time #1260

Open
conradbeach opened this issue Dec 11, 2018 · 5 comments
Open

Datetime Picker Frequently Shows Incorrect Time for Field::Time #1260

conradbeach opened this issue Dec 11, 2018 · 5 comments
Labels
bug breakages in functionality that is implemented fields new fields, displaying and editing data

Comments

@conradbeach
Copy link
Contributor

The Issue

Frequently, the datetime picker in Administrate displays the incorrect value in form fields displaying Field::Times.

This issue can be demonstrated in the example application by changing the type of the published_at attribute in the PostDashboard from published_at: Field::DateTimeto published_at: Field::Time.

You can then observe the following behavior after creating a new Post.

  1. The value for published_at for the Post is displayed as 11:45AM in both index and show views.
    post_before_index
    post_before_show

  2. When you click the edit button, you are taken to the edit form for the Post and the published_at time is incorrectly displayed as 20:45:00.
    post_before_form

  3. If you click save without making any modifications to the form, the Post is updated with the incorrect published_at time.
    post_after_show

  4. If you click the edit button again, the correct value for published_at is displayed in the form.
    post_after_form

Different times behave differently. Some are displayed correctly, some are not.

This behavior is the same whether the database column is of type time or datetime.

I observed this behavior with and without timezones.

I haven't observed this behavior with Field::DateTimes.

My Investigation & Analysis

Administrate makes use of the bootstrap-datetimepicker library to add a datepicker to datetime fields in forms. That library in turn depends on Moment.js for parsing dates and times. Administrate uses bootstrap-datetimepicker via the datetime_picker_rails gem.

The file responsible for rendering Field::Time form fields is app/views/fields/time/_form.html.erb. It renders an <input type="text"> field. If you're editing an existing value, the partial doesn't use a valid datetime format for the value of that field though. It uses a datetime of the following format: 2000-01-01 20:45:00 UTC (or perhaps 1999-12-31 17:45:00 -0800 if you're using timezones).
So you end up with a text input that looks like this:
<input data-type="time" type="text" value="2000-01-01 20:45:00 UTC" name="blog_post[published_at]" id="blog_post_published_at">

If you try to parse that datetime string using Moment.js, you get a warning along the lines of Deprecation warning: value provided is not in a recognized RFC2822 or ISO format. moment construction falls back to js Date(), which is not reliable across all browsers and versions.

So my first inclination was to think that properly formatting the datetime might fix the issue. This can be done pretty easily by changing a line in the app/views/fields/time/_form.html.erb partial from:
<%= f.text_field field.attribute, data: { type: 'time' } %>
to:
<%= f.text_field field.attribute, data: { type: 'time' }, value: field.data.iso8601 %>

This results in a text field that looks like this:
<input data-type="time" value="2000-01-01T20:45:00Z" type="text" name="blog_post[published_at]" id="blog_post_published_at">

This, however, didn't fix the buggy behavior. Even with a valid ISO8601 datetime string, the form field still frequently shows the incorrect time.

If you disable JavaScript, the correct time is displayed in the form field. If you turn JS back on, the time is displayed incorrectly. This leads me to believe that bootstrap-datetimepicker is parsing or rendering the time incorrectly. I don't think it's an issue within Administrate.

I'd like to submit a pull request to address this, but since datetime_picker_rails is no longer maintained, I'm not sure if there's a way for me to do that.

@conradbeach conradbeach changed the title Datetime Picker Frequently Shows Incorrect Time for Time Fields Datetime Picker Frequently Shows Incorrect Time for Field::Times Dec 11, 2018
@conradbeach conradbeach changed the title Datetime Picker Frequently Shows Incorrect Time for Field::Times Datetime Picker Frequently Shows Incorrect Time for Field::Time Dec 11, 2018
@noefroidevaux
Copy link

noefroidevaux commented Feb 19, 2019

@conradbeach I have the same problem.

It seems that administrate do the time parsing with the format option "HH:mm:ss":

So if I use the same format in the _form.html.erb, it works:

  <%= f.text_field field.attribute, data: { type: 'time' }, value: l(field.data, format: '%H:%M:%S') %>

But I'm not sure if it's the "right" solution.

@conradbeach
Copy link
Contributor Author

@noefroidevaux Thanks for the suggestion.

@nickcharlton nickcharlton added bug breakages in functionality that is implemented fields new fields, displaying and editing data labels Jan 2, 2020
@leandrocastro
Copy link

The same thing happening here, but the change is a little more serious:

image

On edit:

image

@aksharj
Copy link

aksharj commented Jul 24, 2020

hi, can anyone please share fix for this, in my case the datetime in not stored in UTC, its stored in user local time while created _at and updated_at get saved as UTC

@pablobm
Copy link
Collaborator

pablobm commented Jul 25, 2020

@leandrocastro, @aksharj: which version of Administrate are you using? Recently there was a change to how the form is rendered. Perhaps it'll fix your issue?

Otherwise, could you please let me know which DB software you are using, and which column types are your affected fields (DB types, not Rails types)? I wonder if this might be related.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug breakages in functionality that is implemented fields new fields, displaying and editing data
Projects
None yet
Development

No branches or pull requests

6 participants