Your comment reads like that is a Bootstap version/"upgrade" of the Ajax Control Toolkit's picker. However it looks to be a completely separate project.
Opening in response to focus and not accepting focus itself means that it can't be controlled by keyboard (or other not pointer related control device) which could be an issue for disability access.
Admittedly a user forced to use a keyboard could just type in the date so nothing is broken for them other than "interface icing" so it isn't a massive issue, and other than that this looks very nice.
It would be good if he explained somewhere why (from a user perspective) this sucks less than the alternatives.
It seems very little different from what Dynarch's calendar offered in 2007 (the new version is still self-contained): www.dynarch.com/projects/calendar
Author here. I do have a time picker in the works but I was planning to have it be a separate project. I suppose it could be a good idea to bundle it with this to avoid duplicating moment.js.
Currently I'm using a heavily hacked third party time picker that was patched onto jquery ui datepicker, and half of the advanced datepicker functions don't work or work badly. It took me a day of research and at least two days of hacking to make this work well: http://imgur.com/87e9g.png , I'd love to see a replacement that just works without any hacking needed :)
This picker seems nice. I'm bookmarking it for any case where a complex datepicker is necessary.
For people looking for keyboard / accessibility support, I personally don't think a datepicker should be attempting to handle those concerns; it's more of a UI polish layer than a primary input method.
On that note, if you're looking for something significantly more lightweight (~8k minified) and easily skinnable, you could check out my own jQuery.minical:
(To clarify my own statements: I'm not saying there's never a time to use a highly accessible datepicker, just that a very common use case for a datepicker is just to provide a visual way to quickly input a single date into a form control.)
I saw the screenshots and demos and immediately disliked it. The default should be that the week starts at Monday. The default String representation should not be `m/dd/yyyy` but instead `dd.mm.yyyy`. There could be additional examples that show the date formats that are used in the usa, but not the first and default ones.
It would be better if clicking in the gaps between day boxes would choose the nearest day box, so that the mouse would not flash between arrow and hand while sliding across it (this is a pretty common UX practice, I think it has a specific name).
I agree, if for example you were using this to make date selections far in the past or future there's a LOT of clicking. Unless there's some way to skip years in larger amounts that I just couldn't find in which case there's a discoverability problem.
The key thing is the ability to click the month/year headings to zoom out.