Break up timepicker's model into separate values

[wesleycho]

This change is to break up the model into separate values, i.e. hours, minutes, and seconds. This is to fix date related issues for a component that shouldn't rely on date objects at all.

[pkozlowski-opensource]

@wesleycho since I'm looking into timepicker in the context of https://github.com/ng-bootstrap/ng-bootstrap I would like to brainstorm here.

I totally agree that using Date object is sub-optimal and we should use another data structure instead. What is your current thinking regarding the exact data structure? For me it could one of:

• string (possibly with a configurable parsing / formatting strategy)
• A predefined data structure (ex. {hour: 12, minute: 15: second: 00})
• any arbitrary data structure where a user is obliged to provide parsing / formatting utility

At the end of the day we want sth like: <input ng-model="timeExp" bs-timepicker> and we need to define:

• allowed values for timeExp
• how to turn value of timeExp to a string (we need it so we can display a selected time in the input field)

Thought?

[wesleycho]

I'm a fan of using an object (second option), that way it is a nice & expected structure, and simple enough for a user to work with (i.e. modifying a date object with the time values to submit to a server).

Allowed values - we should validate that the object is explicitly as we expect (predefined data structure).
Converting to string - given predefined structure, would be very easy to convert to string for each input using a leftPad function.

[pkozlowski-opensource]

I'm a fan of using an object (second option), that way it is a nice & expected structure, and simple enough for a user to work with

I agree. Let's start with this. We could always add more formats as we go.

[sendilkumarn]

I too agree we could use the object. I think it is more flexible.

[icfantv]

specific Issues (individually closed) to address in rewrite:

• form validation
  • manually clearing fields
  • when min/max is used
  • ng-required support
  • support 0 values
  • investigate supporting dynamic values for min and max
• when used in modal
• ng-model-options support
• do not use Date as model object (store fields separately)
• investigate use from within input-group-btn (may be CSS issue on user side)

[alcalbg]

I am looking to rewrite my time tracking utility with ng. At the moment I have time and date tied together so when you push time back beyond 'zero' date will update accordingly to day before. In other words script will update date values if you're pushing time over date boundaries.

For me it is very useful to have this two tied together (time and date) because I think this is more natural behavior for this type of objects.

I don't have a plunker here but you can try this on my demo 'Add Time Entry' button.

[icfantv]

@alcalbg this is something you would best manage yourself and it's not that hard. Using the same Date object for both the date and time picker is fraught with gotchas and corner cases which is why we do not support it.

[pjohnmeyer]

I do second the notion of using an object for the input per my thumbs-up above. I will suggest, though, that the object should continue to use a defined subset of JS Date standard getters & setters instead of direct member access, so that a Date object or Date object proxy can be easily used. Or, introduce your own proxy object interface with a pre-built wrapper for Date. Date certainly has its problems, but it still handles a lot of bad cases for us that I don't want to have to deal with.

[philipp-serfling]

Is there any eta? This bug is making me trouble 6088

[fa-hmad]

Any status on this? Relying on the Date object is definitely suboptimal.