Add $.datepicker.parseDateTime(), $.datepicker.parseTime() functions

[aparshin]

Pull request is related to issue #323.

Some notes:

• parseDateTime() syntax is rather confused - date format/settings are separated from time format/settings. Looks like jQuery datepicker should be patched to fix that. Maybe, some kind of custom lexem parsers for datepicker.parseDate()? Anyway, current hack with error catching should be replaced with more stable method...

• I created several private static functions with parameters instead of Timepicker methods to use them without instance creation. Maybe methods, that work with time object should be separated from calendar's GUI extending/modification into new class. That class can be initialized form string (parseTime() method) and exported back (formatTime()).

• I don't understand this line of code:

  this.hour = (parseFloat(treg[order.h]) + 12).toFixed(0);

  How hour can be not integer? I have replaced that with Number(treg[order.h]) + 12. Is that ok?

• Lexem pairs ("h", "hh"), ("m", "mm"), ("t", "tt") etc. are not distinguished by current parser. Numbering restrictions (for example h < 24) are not validated.

[trentrichardson]

Hey Aparshin, Thanks for the commit, I like where its headed. It will need a few changes before merging, if you mind reviewing?

• The dev branch is now at 1.0.1, could you pull those changes in to yours?
• I believe grouping the parseDate, parseTime and parseDateTime methods together may be a little better organized. Instead of the independent/static methods at the top (getPatternAmpm, getFormatPositions, splitDateTime) if they're only used inside the parseTime, maybe we just declare them inside the method they are used in? or migrate them down to extendRemove (another independent function) at the bottom? And probably just drop completely the Timepicker's internal class methods _getPatternAmpm and _getFormatPositions since they're just aliases now.
• The parseFloat I believe was to avoid when slider steps were less than 0 a decimal could be returned, so that prevented decimals and forced an integer. (parseInt(treg[order.h],10) +12) is probably the better solution..
• Not sure I follow on the last bullet item with the parser, are you refering to the getFormatPositions method? That is essentially a work around since JS regex natively doesn't provide named captures. So it is essentially a shot in the dark that the numbers provided are accurate..

Again thanks on taking the time to help out!!!

[aparshin]

Thanks for code review!

The dev branch is now at 1.0.1, could you pull those changes in to yours?

Done.

I believe grouping the parseDate, parseTime and parseDateTime methods together may be a little better organized.

Do you mean group together in source code (place them in one place of file) or combine into single method?

Instead of the independent/static methods at the top (getPatternAmpm, getFormatPositions, splitDateTime) if they're only used inside the parseTime, maybe we just declare them inside the method they are used in? or migrate them down to extendRemove (another independent function) at the bottom? And probably just drop completely the Timepicker's internal class methods _getPatternAmpm and _getFormatPositions since they're just aliases now.

I move getPatternAmpm, getFormatPositions into parseTime function. Others independent functions (splitDateTime, parseDateTimeInternal) are moved down because they used from several places.

The parseFloat I believe was to avoid when slider steps were less than 0 a decimal could be returinned, so that prevented decimals and forced an integer. (parseInt(treg[order.h],10) +12) is probably the better solution..

Well, currently "order.h" can be only 1 or 2 digits. Decimal numbers won't be matched by regexp...

Not sure I follow on the last bullet item with the parser, are you refering to the getFormatPositions method? That is essentially a work around since JS regex natively doesn't provide named captures. So it is essentially a shot in the dark that the numbers provided are accurate..

I tried to say that there are no difference between 'h' and 'hh', 'm' and 'mm' etc. formats for current parser. For example, "03:09" will be successfully parsed with format "h:m" (in fact, "hh:mm" is more correct format according to documentation). Anyway it is very-minor bug...

[trentrichardson]

Do you mean group together in source code (place them in one place of file) or combine into single method?

Just in the same section of the file, not combined into one function. What you have now is correct.

I move getPatternAmpm, getFormatPositions into parseTime function. Others independent functions (splitDateTime, parseDateTimeInternal) are moved down because they used from several places.

Perfect

Well, currently "order.h" can be only 1 or 2 digits. Decimal numbers won't be matched by regexp...

You're probably correct, it was been a long time since I've touch that portion of the code

Anyway it is very-minor bug...

Ok, I see what you're saying.. We'll just say for now: "very-minor bug" == "unintended feature"

Thanks again, merging now...