Materialize: Timepicker doesn't allow min/max values or disabling hours

[devsware]

Expected Behavior
Like the original pickadate.js, the timepicker should not allow user to select a specific time in a "not available" range.
The date picker manages correctly "min" and "max" options, disabling all the days outside the range set with "min" and "max" option, but time picker seems to ignore "min", "max" and "disable" options (I also tried the different formats that pickadate.js allows for the three options above).

Current Behavior
Even passing "min" and "max" options when initializing the timepicker it is possible to select a time outside the range. The same thing happens if the "disable" option is used (i.e. passing an array of hours that the user should not be able to select like described here http://amsul.ca/pickadate.js/time/#disable-times-use-arrays

Steps to Reproduce
In the following example we are trying to exclude non-working hours of a company from a timepicker.

$('.timepicker').pickatime({
min: [8,0]
max: [18,50]
});

or

$('.timepicker').pickatime({
disable: [0,1,2,3,4,5,6,7,19,20,21,22,23]
});

In both cases it's still possible to select something like 3:00 or 22:50.

Tested on all major browsers.

[Dogfalo]

It's true the timepicker does not allow this. How would you clearly indicate invalid times, since not all selectable times have a label?

[devsware]

Hi,
I imagened something similar to what happens to the date picker for invalid times, like grey-ing out the moment in time that the developer decided to make unavailabe through options.

Since the time picking action is different from the date picking because in the latter you just click or tap on a date (and if that date is not availabe the click/tap just "doesn't happen" for the user), maybe for the time picking action could be a good idea not to let the user select that time/hour or to skip to the next available time slot.

I know it's a bit tricky and articulated and I'm still thinking of a good solution but for now I had this in mind:

When disabling or using min/max ranges with integer values

• when using the "disable" option with only integers it could be done simply grey-ing out the disabled hours (forbidding the user to select them or selecting the first available hour after the forbidden ones).
• the same approach of the previous point could be used when the timepicker is initialized with "min" and "max" options with integers, because in that case the options refer to entire hours.

When min/max or disable are used with something else (not an integer)

$('.timepicker').pickatime({
  disable: [
    [0,30],
    [2,0],
    [8,30],
    [9,0]
  ]
})

or

$('.timepicker').pickatime({
  disable: [
    { from: [2,0], to: [5,30] }
  ]
})

In cases like theese - since the timepicker works separately with hours and with minutes - it's not an option to disable the entire "hour" part when picking the hour, because that could disable the whole 60 minutes and not only the right ones.

Maybe everytime min/max or disable are not integers the "hour" part of the timepicker shoud let the user choose each of the 24 hours (so... no check of any kind on the "hour" part) and then disable only the minutes not allowed by the init options (grey-ing out or skipping automatically to the next available moment).

I understand that with "disable" it's easier because it's unlikely that the option contains a lot of values, while with min/max ranges that would be a little more expensive to realize, but I think that the possibility to disable certain moment in time could be intresting.

For example, when opening the issue I was working on a system that allows customers to select a day and a time to be called back by our staff and I could succesfully disable dates in the past, the sundays and all the holidays, but I wasn't able to prevent them to select an hour outside the opening hours of my company, so I had to add a check after they select the time to warn them that - for example - requesting to be called at 23:00 could result in them being called back the next morning.

Maybe for the UX could be better to show that some hours and/or minutes are not available to be choosen than let the user choose them and then warn him/her that his/her choice was uncorect or not accepted.

[tomscholz]

Maybe everytime min/max or disable are not integers the "hour" part of the timepicker shoud let the user choose each of the 24 hours (so... no check of any kind on the "hour" part) and then disable only the minutes not allowed by the init options (grey-ing out or skipping automatically to the next available moment).

@devsware The 24 hour clock is (I would say) a standard, but you would also have to keep in mind, that there are several countries, where the 12 hour clock is used and since the timepicker supports 12 and 24 hour we would have to respect that.

[devsware]

I understand that the 12 hour clock is indeed used by many countries but I think that the 12/24 hours problem it's something that cames after the initial step of disabling certain hours/minutes of the day.

The Date object in Javascript (please correct me if I'm wrong) manages the hours as integers (without am/pm indications, so I suppose that in any case all the times are 24h based).

From the MDN documentation, a new Date object can be created with:

new Date();
new Date(value);
new Date(dateString);
new Date(year, month[, date[, hours[, minutes[, seconds[, milliseconds]]]]]);

so it's also capable (with the third type of initialization) to parse standard compliant dates that uses AM/PM when initialized but on the documentation of pickadate.js it's explicitly stated that the hour should be expressed as an integer from 0 to 23.

So, the problem it's not while declaring a forbidden moment or time range (since it should by expressed in 24h mode only) but rather how to correctly display it when the timepicker plugin is initialized with a 12 hours mode.

In this case, when the timepicker plugin is initialized with a 12h display mode there should be a translation from the 24h way of indicating the forbidden time intervals to the correspondent 12h intervals.

I know it could be tricky (as I already said in the previous comment) expecially in presence of a range that starts "AM" and ends "PM" (like 10AM to 2PM) or vice-versa, nonetheless for the UX it could be very useful to have the same capability of the original pickadate.js to exclude some time ranges.

Even having the possibility of excluding just entire hours (if the minutes disabling is too expensive to implement) could be a great improvement, insted of listening for a change of the time value and then checking if the time selected by the user is "a bad choice".

[devsware]

I find a way to disable certain hours from being picked (I didn't need to disable minutes for now but it should be easily extended).
My code isn't clean enough yet but I'd like to share this info as soon it was working.

First of all, it's necessary to extend slightly the options of the pickatime plugin to accept a disabledHours option defined as an array of integers (range 0-23 that defaults to an empty array, so that no hour is disabled if the option is not used when initializing the plugin).

Then it's necessary to update the ClockPicker.prototype.setHand function in this way (line 8137 of the dist/js/materialize.js file) by adding:

if(isHours && $.inArray(value,options.disabledHours)>-1)
return;

Since in my case it was enough to disable hours, first of all there is the check to verify if the setHand is actually working on the hours part of the picker and if so we also check if the computed hour (stored into value) is one of the hour of the day we included inside the disabledHours array.

With this fix, everytime the picker is moved over a disabled hour the hand is not drawn and the value is not selected, so the picked hour value is not updated (as a matter of fact we have disabled picking some hours).

To enhance visually the picker I also used the afterShow callback to add a grey-text class to the elements (get by using $(".clockpicker-dial.clockpicker-hours .clockpicker-tick") ) inside the disabled range.

What could be improved
Well... a lot! :)

FIrst of all, if we drag the mouse/touch over a disabled hour, the selected input remains the last valid hour where we moved the cursor/finger.
If the mouseup event is fired the picker switches immediately to the minutes view keeping the "old but correct" value.
Maybe could be useful to disable the switch to the minutes view unless the mouseup event occurs over a valid hour (or maybe not... it's still acceptable this way and the left side of the picker shows the selected hour anyway so it's quite clear what has been selected/accepted as valid input)

Then it could be interesting to add some sort of visual feedback if the user released the mouse/touch over a disabled hour.

More ideas:

• be able to implement intervals instead of listing all the hours we need to disable (like the from: 'someValue', to: 'someOtherValue' used in pickadate.js
• disable values even on the minutes view, but it could be tricky because each hour can have a different set of minutes to disable

[Dogfalo]

Do you have a Codepen illustrating your changes?

[devsware]

Here you are: https://codepen.io/devsware/pen/XgQPbR

On the javascript tab:

• line 7921: the default options of pickatime is extended with the disabledHours variable (it defaults to an empty array, so that if the option isn't specified during initialization, no hour will be disabled)
• line 8140, you can find my fix.

At the end of the javascript tab there is the plugin initialization with the new disabledHours option and the greying out of the disabled hours inside the afterShow callback.
If you try the picker you will find that you cannot position the hour hand over the disabled hours.

[KyDenZ]

Hello,

Will you soon implement this feature in the module?

Thank you