Tempus-dominus: While choosing a new date, time shouldn't be changed

[PoslinskiNet]

Hello,

I've encounter the problem with eonasdan-bootstrap-datetimepicker and moment 2.16.0. I've tried a few versions of Moment already. It was working well with older Moments and Ember bellow 2.8.0. I had to upgrade this package because of a new version of jQuery in Ember (3.x).

The problem is: while changing a date, the time is always set to the current time. Even if I've changed the time, and go back to the calendar - time will be overwritten. Besides that, other behaviours work fine.

Any thoughts, any ideas?

Thanks in advance for any help.

[outshyn]

Just to assist PoslinskiNet & dev team, here is what I experienced.

Created a field with a datetimepicker. Pre-fill field with a date & time. Upon initial display of page, click datetimepicker icon to show calendar. Select a new date. Watch as date changes (good) but then time is adjusted!

EDIT: Watched the console while doing this. This message printed: "Deprecation warning: value provided is not in a recognized ISO format. moment construction falls back to js Date(), which is not reliable across all browsers and versions. Non ISO date formats are discouraged and will be removed in an upcoming major release. Please refer to http://momentjs.com/guides/#/warnings/js-date/ for more info."

My date format is "ll LTS" which is from moment's docs, but I guess moment doesn't like moment's own formats, anymore?

It makes sense that it changes time to the current time, if moment is falling back to Date().

[karolyi]

+1, can confirm.

when initializing a datetimepicker with only a date format (so time picker is unnecessary), it will always set its time to the initialization time on choosing a date.

then, after the picker closed, clicking again on the input field which brings up the datetimepicker again, executes a dp.change event, showing the initialization time as the event.oldDate's time.

currently trying to find ways to mitigate this issue without modifying the source.

[karolyi]

after hours of investigation, here's the root of problem:

when initializing the widget at https://github.com/Eonasdan/bootstrap-datetimepicker/blob/master/src/js/bootstrap-datetimepicker.js#L2343, the widget initializes with the actual moment, that contains the hours, minute and seconds information, even though the format was specified as YYYY-MM-DD.

when opening the picker or changing the date by picking another one, selectDay (https://github.com/Eonasdan/bootstrap-datetimepicker/blob/master/src/js/bootstrap-datetimepicker.js#L1027-L1039) manipulates that originally initialized date, ignoring the YYYY-MM-DD format.

so, when I assign a certain date from the outside that contains a different HH:MM:SS, the dp.change will always fire because the widget has another one within. as I only use YYYY-MM-SS resolution, I set the time to 00:00:00 when changing from the outside. hence, dp.change will fire when it sees that the contained date is different in terms of HH:MM:SS.

workaround until this will be fixed: if you change the date from outside by using date, always use the HH:MM:SS that datetimepicker has been initialized with. thus, dp.change won't fire when you choose the same date OR open the picker.

(massive facepalms, btw)

I don't know who's responsible for fixing this, but please do fix this.

[karolyi]

Better, easier workaround:

when changing the picker's date from the outside, don't just use date(momentInstance), but also viewDate(momentInstance).

this will set the widget's inner stored date to the desired HH:MM:SS, so you won't get dp.change double fires when changing the date or opening the picker by clicking/focusing on it.

[razorcd]

another simple BUG example:
https://jsfiddle.net/66xnfex3/2/

[razorcd]

This should be marked as a CRITICAL bug. It's breaking usability of this datetimepicker.

[benjiew]

I'm getting the same behaviour with 'LT' format - when changing a time, the date part is updating to the current date.

[valeriob]

Any update on this one ?
It seems updated to me since 4.17.45 https://jsfiddle.net/66xnfex3/3/

[William-H-M]

Hi, non of the OP and the one of @razorcd was able to reproduce it on the latest version.
@valeriob can you test it out on your own and see if still happen as following the steps given above didn't seem to happen to me, thanks.

https://jsfiddle.net/William_/20oywuno/

[valeriob]

I'm updating the package in our solution right now since we are not able to reproduce it on 4.15.45.

[William-H-M]

Hi, the latest version, 4.17.47, doesn't have this error. So I'll be closing this.

[PoslinskiNet]

It works 👍

[carlituxman]

I have 4.17.47 and has the error:

moment-with-locales.min.js:1 Deprecation warning: value provided is not in a recognized RFC2822 or ISO format.....

[William-H-M]

@carlituxman this is not an error is a deprecation warning as it says, update your moment.js and don't use string formats like: "12-25-1995" use moment("12-25-1995", "MM-DD-YYYY");

http://momentjs.com/docs/#/parsing/string/