Timefield.increment Override? (Displaying 11:59 PM)

[Steve_Terry]

Hi there,

I currently have 2 timefields (1 for "Start Time" and another for "End Time") whereas my objective is to restrict the daily time bounds as follows...

Start Time: 12:00 AM - 11:00 PM
End Time: 1:00 AM - 11:59 PM

The selectable values in both timefields can only be hourly (no minutes/seconds so I set the increment config to 60).

As examples, the timefields look identical to...

{
   xtype: 'timefield',
   itemId: 'StartTime',
   minValue: '12:00 AM',
   maxValue: '11:00 PM',
   format: 'g:i A' //Not required since default
   increment: 60, // Display only hour values, not minutes/seconds
},
{
   xtype: 'timefield',
   itemId: 'EndTime',
   minValue: '1:00 AM',
   maxValue: '11:59 PM',
   format: 'g:i A' //Not required since default
   increment: 60, // Display only hour values, not minutes/seconds
}

The problem is that the "EndTime" timefield's maxValue is not being set properly whereas it appears that the increment config is overriding the maxValue by cutting off the minute values and only displaying a maxValue of 11:00 PM.

I would expect that by setting the maxValue it would override any previous increment settings since setting the maxValue/minValue are only concerning the bounds of the selectable times.

I looked into the source code for any potential overrides I could include for the class and found no more information regarding the increment config besides it simply being set to a value inside the class.

I have even looked into the class "setMaxValue and setLimit" methods and could not determine what to change at that level as well.

There has to be some sort of potential workaround whereas for the "EndTime" timefield I am able to display the times from "1:00 AM to 11:59 PM" separated hourly so in the end once the picker for the timefield is expanded, it looks similar to...

[1:00 AM, 2:00 AM, ........, 10:00 PM, 11:00 PM, 11:59 PM]

Or potentially a way to apply the increment config and then immediately set the maxValue to "11:59 PM" to avoid the maxValue minutes being cut off since the increment config must be set to 60.

Thanks in advance!

[Steve_Terry]

Another alternative I attempted was to add "12:00 AM" to the end of the "End Time"'s picker list such that it looks similar to...

[1:00 AM, 2:00 AM, ........, 10:00 PM, 11:00 PM, 12:00 AM]

whereas 12:00 AM would indicate the midnight or (aka next day)

however every attempt at adding "12:00 AM" has just forced the "12:00 AM" to the front of list and not the back.

[Steve_Terry]

To fix the issue and display the picker list of the timefield currently in terms of...

[1:00 AM, 2:00 AM, ........, 10:00 PM, 11:00 PM, 12:00 AM]

I had to override the following (in red) sections of the "TimePicker" class functions...

createStore: function() {
        var me = this,
            utilDate = Ext.Date,
            times = [],
            min = me.absMin,
            // Ensure the list contains 12 AM
            max = utilDate.add(me.absMin, Ext.Date.DAY, 1)

        while(min <= max){
            times.push({
                disp: utilDate.dateFormat(min, me.format),
                date: min
            });
            min = utilDate.add(min, 'mi', me.increment);
        }
        
        return Ext.create('Ext.data.Store', {
            fields: ['disp', 'date'],
            data: times
        });
    }

updateList: function() {
        var me = this,
            utilDate = Ext.Date,
            min = me.normalizeDate(me.minValue || me.absMin),
            // Ensure the filter is set to include the max (aka 12 AM)
            max = utilDate.add(min, Ext.Date.DAY, 1)
            
        me.store.filterBy(function(record) {
            var date = record.get('date');
            return date >= min && date <= max;
        });
    },

I only had to make the change for 1 timefield so I retrieved the itemId of the timefield via...

me.pickerField.itemId

Of course there are most likely several improvements to my workaround!

Hope it helps someone who searching for the same.

[scottmartin]

Thank you for the update!

Scott.

[Steve_Terry]

Your welcome Scott!

I'd rather not mark my answer as "Best Answer" since that just doesn't seem right.

If someone can potentially post a modified more efficient version of what I wrote above I can mark that as "Best Answer"