Add jQuery Timepicker for the Time element of the datetime field

I guess you had a concrete differentiation in mind when filing this issue, but can you clarify why this is not a duplicate of #1835016: Polyfill date input type?

tagging

looks like we are using http://keith-wood.name/timeEntry.html in D7 for time picker and it is very close to HTML 5 time picker (Except the arrows in right). Are we OK to add it to core for time?

First pass using http://keith-wood.name/timeentry.html Seems to work in FireFox.

Not sure if/how to write tests for this. Also not sure sure how to handle the localization here.

Should I just be able to install this with SimplyTest.me?

#10, that should work, but I haven't tried it. I think for the test, we could just render out a page w/ a datetime field on it or a timestamp entry (eg, the node form) and then check for the CSS and JS files.

Thanks for the patch.

If you testing in http://keith-wood.name/timeentry.html, don't you think it's UX problem ? I feel that hard to use.

#12, that library was used b/c it is what is currently in the D7 Date Popup module. I agree that the UX isn't the best, however, it seemed like the least bad solution of the plugins I surveyed. Unfortunately, jQuery UI doesn't have an official option yet. I'm open to other options here.

The proposed timepicker is super unusable, at least in my testing.

If it were totally up to me, I'd really actually prefer to use the popup calendar for the date, but then a select list for the time. Maybe something like this https://www.drupal.org/project/stanford_date_timepicker

I'd happily entertain another timepicker, especially if it is more usable. I didn't run across that one when I was searching. If anyone wants to reroll the patch feel free, otherewise I will update it one night this week.

If we are choosing a timepicker, here is my favorite:
http://jonthornton.github.io/jquery-timepicker/
This looks like the simplest UI and most familiar to me:
This timepicker is similar to Google Calendar & Outlook timepickers. It uses standard/default form elements.

I'm not a fan of the small & non-standard buttons of http://keith-wood.name/timeEntry.html.
I agree the UI of this option is not very intuitive.

https://www.drupal.org/project/stanford_date_timepicker the pop-up window means more formatting and layout work is probably needed to match any given theme.

If we are choosing a timepicker, here is my favorite:
http://jonthornton.github.io/jquery-timepicker/
This looks like the simplest UI and most familiar to me:
This timepicker is similar to Google Calendar & Outlook timepickers. It uses standard/default form elements.

This one looks great! I like that it is non-obtrusive if somebody wants to enter in a time not in the list.

++ for that ^^

I change my vote to #17!!!

Ok, here's a reroll w/ http://jonthornton.github.io/jquery-timepicker/ w/ the default options (well, need to set time format). Any we want to set? Since this is a polyfill, I don't want to add these to the field settings, and just set some sane ones in core/misc/date.js

No interdiff b/c it is too messy.

Tested in FF on OSX.

Ok, let's remake that after I adjust my .gitignore to just ignore the root /vendor directory...

I manually tested this on Firefox and it works as expected. On Chrome (which has html5 support), it has no impact as expected.

This is tagged as 'needs accessibility review', but with this library is that still the case?

Manually tested on ie11, and it looks good.
Manually tested on Chrome, and it has no impact (as expected). BUT, personally, I actually like this timepicker better than the chrome HTML5 picker. But, that is out of scope for this issue....

This is still tagged as needing accessibility review. Aside from that I think this is RTBC.

BUT, personally, I actually like this timepicker better than the chrome HTML5 picker. But, that is out of scope for this issue....

Let's add a follow-up to make this a configurable widget that would override the native time picker.

1. --- /dev/null
   +++ b/core/assets/vendor/jquery-timepicker/jquery.timepicker.css
   

   Tabs are use all over the css file instead of whtespaces, resulting in 'whitespaces errors' when applying patch.

2. +++ b/core/assets/vendor/jquery-timepicker/jquery.timepicker.min.js
   @@ -0,0 +1,7 @@
   \ No newline at end of file
   

   Doesn't this takes newline at EOF ?

Also manually tested give no result on Chrome (as expected) and this on IE:

It fills odd to me. I don't like that datepicker to have useless seconds in suggestions, plus the design does not seems... similar ... to the datepicker of the date part.

Last but not least, a JavascriptTestBase could be nice as a follow-up, actually could be in the new test for #ajax / js tests on elements introduced in #2781103: Date FAPI element type do not allow AJAX via #ajax API

Thought I responded to this. #28-1,2, since those are vendor files we use them as-is and don't apply Drupal coding standards to them.

Open to suggestions for different configurations options.

JSTB. What would we want to test? We don't need to test the polyfill itself, just that it works? Since PhantomJS is WebKit, I am not sure if this would even work? WOrth looking into, though, as a followup (would probably want to combine with coverage of the date polyfill).

@mpdonadio:

1- Good point: the file is in vendor, my bad.

2- Would something like (http://jonthornton.github.io/jquery-timepicker/) with 13:00 or 01:00PM be better then 01:00:00 ? Meaning removing the seconds ?

3- Also for the test I wanted to suggest checking that the popup pops-up. But maybe I'm wrong on it indeed !

4- Could we style the popup with something more drupal-like ?

I agree removing seconds should be done. They're useless in there. Seconds can of course be added manually.

The timepicker library has an unbind function. I wonder if this patch should add a "detach" JS function that invokes it, just like the date picker does.

also look at this: https://www.drupal.org/sandbox/ujshah18/2685025

The only setting we are manually making to the timepicker is the time format. This prevents me from being able to set the time format via a data-time-format="H:i" or whatever format I want, as timepicker is using the options passed in directly to the timepicker call.

Can we modify this to either
1. Remove default format so others can override with data attributes
2. Allow setting this default format in config
3. Parse #date_time_format and use that instead for consistency?

for es6

Re-rolled.

This needs to be rerolled for the ES6 change, #2815083: Drupal core now using ES6 for JavaScript development.

However, I am not 100% sure what that means for the polyfill library. I think that means it needs to be in package.json, but I don't think we have any external dependencies committed yet and I am not aware of any other patches to look at for guidance.

I think that means it needs to be in package.json

At the moment, we only maintain the build script packages in package.json. Other than that, all still remaining same way.

Working on this, mainly so I can get my D8 ES6 environment going.

This should be a good ES6 reroll. Also updated the polyfill to the latest version.

If we are OK with this library, we could probably also add a JSTB to this now.

+++ b/core/misc/date.js
@@ -11,6 +11,8 @@
+      var _this = this;
+
       var $context = $(context);
 
       if (Modernizr.inputtypes.date === true) {
@@ -31,6 +33,14 @@

@@ -31,6 +33,14 @@
         }
         $input.datepicker(datepickerSettings);
       });
+
+      $context.find('input[type="time"]').once('timePicker').each(function () {
+        var $input = $(_this);
+        var options = {
+          'timeFormat': 'H:i:s'
+        };
+        $input.timepicker(options);
+      });

The transpiled version is borked b/c the fat arrow (forgot `this` gets handled differently, http://exploringjs.com/es6/ch_arrow-functions.html). This fixes that.

Also added an unload event.

We probably need a test or two here?

Firefox soon will get this enabled https://blog.nightly.mozilla.org/2017/06/12/datetime-inputs-enabled-on-n...

Did not apply to the latest 8.5.x git checkout. This re-rolls the patch for the latest. I have not added any tests as of yet.

This is still at needs work for tests.

Same patch as 46 except removed seconds. So 'H:i:s' is now 'H:i'. The system will automatically save the the date with '00' for seconds.

We should give users the option to choose 12 (h:i A) or 24 (H:i) hour format .

The patch in #50 no longer applies to 8.7.dev.

Fixed problem with indentation in date.es6.js
Setting to needs review to run testbot, still needs tests.

@jhedstrom any thoughts on how this should be tested?

#52 doesn't seem to work if the browser supports HTML5 date pickers.

By moving the time picker code to above the modernizr return it seems to work fine for me (although I have no idea at all if this is a proper way of solving the issue).

(Leaving at NW since it still needs tests)

Here is a version of this patch for 8.6.x since there was not once available.

1. +++ b/core/misc/date.es6.js
   @@ -45,6 +45,14 @@
   +      $context.find('input[type="time"]').once('timePicker').each(function () {
   

   Use an arrow function here.

2. +++ b/core/misc/date.es6.js
   @@ -45,6 +45,14 @@
   +        let $input = $(this);
   

   With the arrow function you don't need `$(this)`.

3. +++ b/core/misc/date.es6.js
   @@ -45,6 +45,14 @@
   +        let options = {
   

   Use `const`

#56 works on 8.6.x. Here's a version of it without the seconds.

#61 failed. This is the fix for 8.6.x.

#62 Works great, tested in Safari! Thank you!

Will this conflict with modules like http://drupal.org/project/date_recur?

@SocialNicheGuru I used it with date_recur and it works great.

A couple of questions/comments, as a backend dev looking at integrating this support:

1. We would want timeFormat to default to the time format configured for the field - the date picker does that, can we do that for the time picker?
2. What mechanism is there for setting options? In our case, we want step to be 15...

Thanks.

Updated the remaining tasks in the IS.

patch still applies to 8.9.x

however does not apply to 9.0+

In this change record it has been decided core will no longer use a polyfill for the date element: https://www.drupal.org/node/3081864.

Closing this as won't fix as it would seem very unlikely that core would add support for a polyfill for the time element.

Note: for those that still require this feature: the patch doesn't apply because jquery ui datepicker has been removed in https://www.drupal.org/project/drupal/issues/3072906.