Bootstrap-datepicker: Hope you can add Time support

[camsong]

I can only pick a date, but without hour and minute, hope you can add time support, thanks.

[Nerian]

That would be really useful for me too

+1

[gagarine]

I get this screenshot from https://beta.capitainetrain.com. I really like how they deal with hours and certainly going to implement that on top of bootstrap-datepicker.

[Nerian]

The makers of Trello have it this way:

Looks nice to me.

[gagarine]

@Nerian This is not a date time picker, it's a date picker with a time field. I don't see the advantage of that against a separate time field. You have to click a lot and use your keyboard and mouse.

My example should be of course extended. But the idea is if you are in a "picker" (so you want to use your mouse) you should just click. Otherwise if you want to use keyboard you just write your date in the field without the help of a date picker.

[eternicode]

@gagarine I can't see that on the page you linked -- looks like it's trapped behind a login. Looks interesting, though.

Also, keep in mind that bootstrap-datepicker does support keyboard navigation ;) So that would have to be taken into consideration.

I'm just leery to add time functionality -- there are questions of visual integration, programmatic integration, UX, accessibility (keyboard nav), and I'm not sure there's that much advantage over a simple text input next to the datepicker (or even a separate "timepicker" plugin, maybe). Aside from looking pretty and being conceptually cool ;)

[gagarine]

@eternicode yes it's a beta and you need to create an account.... know it's sucks.

I think you right it will not be useful for a lot of people and can be complicated in a lot of way. This will certainly be better as an optional extension.

[loekwetzels]

+1 :)

[amnesia7]

Maybe these are worth a look for layout/function: http://trentrichardson.com/examples/timepicker/ and http://addyosmani.com/blog/the-missing-date-time-selector-for-jquery-ui/

[gagarine]

@amnesia7 slider doesn't seem good for me for people with disabilities and touch screen. What I'm thinking of is a fast way to input time with the less possible click and only click (no drag, right click, keyboard input, ...).

I also think the time and date have to be in on field so it's easier to edit with keyboard (not everybody use tab). But I'm not sure about this... have to try with some user.

I sadly don't have time right now to work on that but I hop I can come back on this project in some weeks.

[amnesia7]

@gagarine, maybe something along the lines of http://2007.electronicholas.com/calendar

[tkrotoff]

Or something like Google Calendar does:
http://labs.perifer.se/timedatepicker/
https://github.com/jonthornton/jquery-timepicker

[eternicode]

@jdewit has written a bootstrap-timepicker plugin. It could use some improvement, but those of you needing a timepicker might look at it in the meantime.

(Note: this is not an "official" endorsement, just another option. Although I do like this one's interface the best so far :) )

[amnesia7]

@eternicode, I know timepicker is not your project but while we're throwing UI suggestions around for a timepicker as part of a datetime picker I just thought I'd mention that the bootstrap-timepicker might be quicker to select times (rather than keep clicking up or down arrow) if it could be scrolled using the scroll wheel like this one: http://demo.mobiscroll.com/
I also found this one which is along the lines of the suggestion by @gagarine : http://ejohn.org/blog/picking-time/

[gerwitz]

I think I have a different motivation for using datepicker than some of you. I think of my input fields as text, which means keyboard-oriented, but like datepicker for letting my users pick "last saturday" intuitively.

But I also need time in the same field (partially to support iOS's datetime input control). So I'd like time support to start with a simple tweak: allow the underlying field to have time values without overwriting them when the picker is invoked.

[cemo]

+1 for this feature

[cemo]

By the way the best option so far for me after investigating quite different alternatives is jquery.timepicker [0]. In addition, the typeahead might be utilized.

[0] : http://jonthornton.github.com/jquery-timepicker/
[1] : http://twitter.github.com/bootstrap/javascript.html#typeahead

[greyblake]

+1 for this feature.

[JNajera]

+1 for this feature!

[cristianm]

+1 for this feature!

[ButuzGOL]

+1 for this feature!

[wormling]

+1 for this feature!

[lewispb]

+1 for this

[bendo01]

+1 for this :)

[cemo]

@eternicode

What do you think about this implementation?

http://trentrichardson.com/examples/timepicker/

[mren]

nice datepicker @eternicode :)

i want to throw anytime.js into the race. A very usable datepicker.

[chrisgo]

+1

[stabenfeldt]

+1

[freshfey]

+1

[smndhm]

+1

[vikassaklecha]

+1

[GBH]

:+1:

[jmuheim]

+1

[durasj]

+1 for http://trentrichardson.com/examples/timepicker/

[cemo]

@eternicode

Don't we deserve a date for this issue? :)

[ROFISH]

+1

[jmondo]

+1 definitely jumping on this bandwagon

[Yohn]

https://github.com/jdewit/bootstrap-timepicker

[eternicode]

@Cemo How about "someday" ;)

On the one hand, I'm focused on bugfixes right now, when I can get the time to look at them. At some point I'd like to finish some of the other "new features" -- ranges, backends, etc -- and get them merged in.

On the other hand, though, this is probably the most-commented issue in this project. So, yes, while I'd rather not look at it now, it does deserve at least a little discussion (though it has already had a little).

Individual comments:

http://www.ama3.com/anytime/
An interesting approach, but as it is now it's overkill, IMO. If we can find a reasonable way to put 24hr + minutes alongside the days in this style, maybe -- not sure.

http://trentrichardson.com/examples/timepicker/
I like the slider-based version, but worry about keyboard accessibility (plus I'm not aware of any bootstrap slider plugins -- yet ;) ).

http://labs.perifer.se/timedatepicker/
http://jonthornton.github.com/jquery-timepicker/
These two are pretty identical, though the latter seems to have more features/options. But this is the simplest and most compact approach so far, I think I could get behind this. Though I think if it were integrated with datepicker it'd be better off as an integrated <select>.

http://2007.electronicholas.com/calendar
Similar to the last one, but with two separate fields for hr/min. Not sure of my feelings in separating the two.

http://jdewit.github.com/bootstrap-timepicker/
As much as I like the aesthetics of this one, it's probably the least usable and feasible :)

Of course, any approach we take is going to need some way to switch keyboard focus between the "date" and "time" areas.

[cemo]

@eternicode

Personally I like the slider version. It is very compact and suits better with bootstrap-datepicker.

By the way, any kind of roadmap could be really great. :)

[monemihir]

+1 definitely for this feature.

First of all, thanks a lot for this awesome plugin. It works really well with my project.

I am moving away from jQuery UI to Bootstrap and therefore would really appreciate this functionality.

I am actually dealing with C# DateTime objects in the .NET MVC world which auto binds data from text boxes to class variables and therefore having the date and time show up in the same text box is much easier to handle than having to manage 2 text boxes and make a datetime from that.

Ideally I would actually like to be able to specify a data-format like dd-MMM-yyyy hh:mm for the text box which would be just awesome.

[itkin]

+1

[jeremyhaile]

+1

[orloffv]

+1

[assembler]

+1

[mrpotts]

+1

[gureedo]

+1

[phkavitha]

+1

[langri-sha]

+1

[MartijnR]

+1

[dikirill]

I've added time formatting support, just replace object 'DPGlobal' by mine:
http://jsfiddle.net/K2ts2/1/
This change will prevent control to erase your specified time.
Hope it will help you in meantime, while we're waiting for a time picking feature.
[Update]
Actually, try to use https://github.com/Nerian/bootstrap-datepicker-rails, it doesn't remove time manually posted, and this version much more advanced.

[andrewshkovskii]

+1

[nexeck]

+1

[eugenebunin]

+1

[hinti]

+1

[areski]

+1

[grohman]

+1

[adayth]

+1

[ksnyde]

+1

[ksnyde]

is there a way -- while we wait with baited breath for the time functionality -- that I can configure the current implementation so that it won't erase the time information that I type in manually? I have the following format defined in JS:

    jQuery(target + ' .datepicker').datepicker({
        format: 'yyyy-mm-dd'
    });

I tried also tried:

    jQuery(target + ' .datepicker').datepicker({
        format: 'yyyy-mm-dd 00:00:00'
    });

both behaved quite badly with my time information. You see i could live with -- in an admin screen -- the datepicker choosing the date if I could then punch in the time manually into the field. Not elegant but it'd get me by until elegance is an offered feature to the time-hungry amongst us.

[scharc]

+1

[supersuphot]

+1

[ksnyde]

+10

Still struggling with my datetime fields. Does anyone have any code that addresses splitting the date and time apart and then reassembling them before form submission? I need a work-around to the lack of time support (or at least some time support in the format() function for time variables that are set.

[vitalets]

Another timepicker that can be usefull for this issue.
http://vitalets.github.com/clockface

[assembler]

http://tarruda.github.com/bootstrap-datetimepicker

[rchavik]

@assembler nice find

[eternicode]

What do y'all think of this version:

http://www.malot.fr/bootstrap-datetimepicker/

It's the first version of a datetimepicker that I really like, because it integrates into datepicker's existing "views" concept (adds a day view and an hour view for picking hour and minute, respectively).

[ksnyde]

Seems very good for some use-cases and not others but at first blush looks
very well done.

On 2 January 2013 18:02, Andrew Rowls [email protected] wrote:

What do y'all think of this version:

http://www.malot.fr/bootstrap-datetimepicker/

It's the first version of a datetimepicker that I really like, because it
integrates into datepicker's existing "views" concept (adds a day view and
an hour view for picking hour and minute, respectively).

—
Reply to this email directly or view it on GitHubhttps://github.com/eternicode/bootstrap-datepicker/issues/29#issuecomment-11817481.

[eternicode]

@ksnyde "not others" -- for example? What if it was combined with maxview/minview, a la #246?

[smalot]

Note that I've implemented too minview and maxview.
The current step is 5 minutes which is hard coded. it could be overridable
be setup with a small development ...

Le 2 janv. 2013 21:29, "Andrew Rowls" [email protected] a écrit :

@ksnyde "not others" -- for example? What if it was combined with
maxview/minview, a la #246?

—
Reply to this email directly or view it on GitHub.

[eternicode]

Yes, the increments would probably become settings, with the current values (1 for hours, 5 for minutes) as the defaults.

[ksnyde]

Well it appears to suit the situations where a "drilldown" makes sense
(aka, date, then broad timeframe, then specific timeframe). It takes three
clicks but it does have an intuitive flow that people will find easy to
understand and use. Here are a few other use-cases that happen in the real
world that I think this control might be cumbersome with:

1. Intraday events. Context would typically provide the most-likely

date so you would want the UI to primarily give the user time controls but
the field should carry both date and time. You might optionally have the
user be able to roll back to the date to set intraday events near day
boundaries for instance).
2. Cross-day events. Thinks like sleeping are a good example of this.
The date is fixed on "yesterday" but if you move past midnight the control
should programatically shift to the "today" even though the user is just
manipulating time. In this use case you'd only want a small notification of
the day it's operating on so the user knows that things are being taken
care of for them.
3. Generalisations. There are times where you want the user to focus on
a date but specify "roughly" when during the day the event took place.
Typically you would use monikers like "morning", "afternoon", etc. and then
programatically you could shift the times to approximate times even though
the user has no access to this. The key is not to put it into the
"drilldown" format as this implies intrinsically that detail holds value
and that choosing "morning" is just the first step in arriving at a
detailed time. In many cases detail like this gets in the way.

I know you can't have it all and this implementation is impressive in
several ways but when you're goal is to limit clicks I think this
implementation is not at its strength.

On 2 January 2013 20:29, Andrew Rowls [email protected] wrote:

@ksnyde https://github.com/ksnyde "not others" -- for example? What if
it was combined with maxview/minview, a la #246https://github.com/eternicode/bootstrap-datepicker/issues/246
?

—
Reply to this email directly or view it on GitHubhttps://github.com/eternicode/bootstrap-datepicker/issues/29#issuecomment-11822863.

[tarruda]

Hello all

You guys should check the latest version, I have added more examples.

@smalot, good job with your fork, I have also implement day/hour/minute views like in your version(you access those by clicking in the hour/minute/seconds), as it is more friendly for touch-based interfaces.

@ksnyde, another use case where a view-based datepicker is not friendly is when you want to allow keyboard-only fast input. Thats why I have implemented a mask functionality in my fork where the user only has to type numbers(static mask components are inserted automatically)

[ksnyde]

@tarruda your fork continues to look good. One thing I'd like to see is when you're in "timepicker" or "datepicker" only modes that you can still put both time and date into the input field. This allows the field to carry both types of data but only ask the user for the part that's important in a given use-case. It may be possible in your plugin but the examples don't illustrate it so I am for the moment assuming it is not.

[cemo]

In terms of usability I would prefer fork of @tarruda . An average user will definitely have some problems to use _extreme view concept_.

+1 for @tarruda

[tarruda]

@ksnyde though I haven't tried this, you should be able to use a complete date/time format(eg: yyyy-MM-dd hh:mm:ss) on a 'timepicker' or 'datepicker' only mode.

I have designed in a way that the 'text input' and 'popup widget' are two different ways in which a user can enter dates.

In the tests you can see that it is possible to use a 'ms' component in the date format, so you can enter dates up to milliseconds precision while in the popup widget this is not available.

Also, besides a 'timepicker-only' and 'datepicker-only' it should be straightforward to implement a 'no-widget' mode where only the masked input is available.

[eternicode]

@cemo, I disagree that users would have problems with "extreme views". Like @ksnyde said, the drilldown process is really straightforward -- the only thing that I might worry about them being confused with (and it's already a problem anyway) is navigation _upward_ (from month view to year view & etc). It's not clear that the calendar title is the mechanism to achieve this... but that's another issue ;)

@ksnyde, you've got some good points. 1) (intraday events) I think can be addressed with minview/maxview -- a default date combined with limits to the hour/minute pickers (maxview="day") ought to populate the input appropriately while only bothering the user with the relevant portions. 2) (cross-day events) is a good point, and I agree that @tarruda's implementation would be stronger than @smalot's in that scenario with its potential for using a "rolling date"; however, the prev/next arrows can still be used to change the day in @smalot's implementation. For 3), generalizations could indeed be part of the drilldown, but as a replacement rather than a supplement to the hours/minutes -- not entirely feasible in the current code (_another_ option!!), but perhaps future changes will make it easier to do things like this.

As for your comment regarding click limiting, I disagree. @smalot's is much stronger than @tarruda's here, for most cases -- perhaps not so much if the _precise_ hour/minute the user wants is not within the given increments, but if they are, it's 3 clicks (select day, hour, minute) vs 1+N+M clicks (where N is the number of hours and M the number of minutes the initial time is off by; arrow buttons ~_~ ), or a minimum of 3-5 (open timepicker [1 click], click+select [2] hour, click+select [2] minute).

If it were purely based on what worksforme and what's more aesthetically pleasing, @tarruda's wins (it's definitely more sexy ;) ). But considering more factors, I still strongly prefer @smalot's.

Please understand that I'm willing to change my stance if compelling evidence is provided; I just have yet to see compelling evidence! :)

(As an aside, I'm hoping to, eventually, get some sort of plugin infrastructure implemented that will allow all these implementation details to become separate plugins -- at which point everyone wins.)

[ksnyde]

@eternicode I don't envy your position, there are a lot of discrete and, at times, contradictory requirements out there. My only ask is that you weight slightly heavier the use-cases where the user's context is used rather than ignored. As a for instance, in the case of how many clicks are needed between the @smalot versus @tarruda implementations I think the answer comes down to how much context do you have? Are you starting from a blank slate or can you start the date/time "close" to the right answer where what you're asking the user to do is fine tune? In many cases the approximate time is already known; a surprising number of use cases come close to predicting based on the current time, others use some other signal to indicate the best-guess. Anyway, I think well designed solutions always aim to incorporate this context wherever possible. I'm sure I'm preaching to the choir here.

I'll step out of the way and say I'm glad you're giving this functionality your attention and I'm sure what you come up with will be of use to me. Even your existing widget with some basic time functionality would help me with some hurdles I'm currently facing. Best of luck and I look forward to seeing where you go with this. :^)

[vitalets]

maybe just let guys develop both solutions and keep this fork simple for date picking?

[tiagoa]

Can be it? http://tarruda.github.com/bootstrap-datetimepicker/

[mosalski]

Hello guys, I am currently developing system which is based on occupancy schedule with yearly view and I found it's very useful to integrate it with datepicker. System UI is based on bootstrap so here is my opinion:

@smalot vs @tarruda:
I agree with @eternicode concerning @smalot solution is the best possible solution for this issue, IMHO.
@tarruda solutions looks 100% cute, yeah! But as @eternicode said it will require tons of clicks to set the required time. @ksnyde , I would agree that there are use cases, when time is already known and in this case timepicker is used just to be sure it's correct or may be fix it by one or two hours, for example, hotels check-in and check-out are usually the same. BUT there are tons of example where there is no such a "signal" which could help me to predefine the correct time for timepicker. Examples: car rental, bus tickets, airline tickets, personal schedules like Google calendar, etc. Also in my system there is no such a signal so I personally find @smalot solution the most user-friendly solution.

@gagarine:
In my opinion, this solution requires too much space for picker, also timepicker not precise enough. In case if we increase precision, design will become a bit messy.

@tkrotoff
Looks, simple, effective and cute. It was the best solution for me before I found @smalot solution. It's inspired by Google Inc. and I'm a big fan of them. Google Calendar is just great) But @smalot solution is native to bootstrap datepicker, while yours is a seprarate datepicker-independent solution.

@vitalets
I really enjoy your x-editable plugin! But I can not say the same thing concerning your clockface plugin. Its very attractive to select time with it, but I'm afraid it lacks user-friendliness.

@amnesia7
Solution with slider looks native and cute, but I can not find any bootstrap slider plugin yet. i see it als ohave a solution for touch screens too(separate buttons). Obviously, this requires more work to implement but this may become quite a good solution. May be even better than @smalot solution.

I currently use my custom modification of @eternicode datepicker as a part of @vitalets x-editable plugin and now I am planning to add timepicker there.

[vitalets]

@InVeX great post, man!
yeh, clockface is not too intuitive although impressed me at the beginning ;)

For me seems the best option to keep @eternicode datepicker as is for date only: it will save size and maintaining efforts. Timepickers are different for different tasks, you just select which to use.

[mosalski]

Ok, so I made an attempt to combine @vitalets x-editable with @eternicode datepicker and @smalot datetimepicker.. and I didn't like it.

I understood that time is an independent parameter in UI and it's not the best idea to mix them in one field and plugin. I decided to use @tkrotoff solution combined with x-editable.

[GBH]

I ended up using http://www.malot.fr/bootstrap-datetimepicker/
It's pretty kick-ass.

[rchavik]

@eternicode

Can you consider including this item for the next milestone?

[heyallan]

+1 for time picker.

[michael-zock]

Another +1

[OndeVai]

+1!

I don't want to have to use a whole separate plugin just to get the time into the date.

We are considering rolling our own on top of this datepicker. We like the ability of having the user always seeing the time and being able to update the time without too many mouse clicks. I like the "google" example above. Although simplistic, it seems the most intuitive and requires less mouse clicks.

[korun]

+1 for time support.
Very often it is necessary to specify the time in addition to date. And it would be very cool to have a single tool for this.
It may be something like @tarruda gem, but without support click-event for the time fields (hours, minutes, sec.), it be more easier and lightweight.

[jeremyhaile]

I really like bufferapp.com's modification to support time. Would love to see something like this be an option: (I'm trying to ask them to open source these changes)

[OndeVai]

Yes! That's exactly what we'd like

[joelg]

Hi guys! Joel from Buffer here. We'd love to open source our date time picker which @jeremyhaile shared a screenshot of above. I just chatted with our CTO @sunils34 and Front-end Engineer @nieldlr and we're going to try and make this happen soon. We'll comment here once we have something for you to play with :-)

[michael-zock]

Joel, this would be a great addition!
I my case the problem is that I need a date picker that can specify the datetime value right down to optional hours and minutes, but which can also display a read-only column of the calendar week number. To my knowledge, this would be the first fork of the original project that's actually able to do both.

[salixzs]

If this and http://www.malot.fr/bootstrap-datetimepicker/ could join efforts...

[jeremyhaile]

@salixzs I actually use the malot.fr version now, but I'm really not a fan of the way they implemented their time picker. The screenshot I pasted above from Buffer that @sunils34, @nieldlr and team built is a much better flow for selecting date and time in my opinion.

[korun]

Too many clicks in malot.fr version, in my opinion.
This interface is not intuitive, time-inputs is not visible immediately.

[salixzs]

We can count clicks. In specific setup malot.fr will have less clicks to set specifiic time than others.
About usability - malit.fr follows the same pattern as setting years->Months->Date[->Hour->Minute] in opposite when you have time setter below date setter all the time. I imagine use cases when clicling hour, minute dropdowns in bufferapp.com version will p**s me off to select "01:00" from default (preset current) "19:39"

[jeremyhaile]

@salixzs you're assuming the user always needs to change the time. If the time is already set correctly, the malot.fr version takes more clicks. We often prefill the time and the user may or may not need to change it.

malot.fr also forces you down a path of setting time. What if you click a date and it then shows time...but you want to go back and change the date. It's not clear how you can do that. With the buffer version, everything is right in front of you and accessible at any point.

I've seen my users get confused by the malot.fr version and I'm not a fan. I find buffer's version much more intuitive. But to each their own - if you prefer malot.fr's version - then use it! That's why we have open source and forks =)

[OndeVai]

Agreed, also not happy with malot.fr version and the hidden time fields

[gerwitz]

@nieldlr if you could offer an "increment" option for selecting only 15-minute (for example) increments in the minutes field, that'd save us from forking. :-)

@salixzs counting clicks was a fine technique for the 1990s, but the HCI community has far stronger measurements techniques today if you want to try quantifying your preference. (It won't fair well, though, due to the linear disclosure.)

[korun]

@jeremyhaile, I absolutely agree!
Moreover, if the date is set correctly, and the user only need to adjust the time, he clicks and... stalled. "Where is the input to change the time?" :anguished:
And for changing time he should once again click on the specified date!

[tarruda]

@Eonasdan is actively maintaining a good datetimepicker here

[jeremyhaile]

@tarruda I do like that one pretty well. The only thing I don't like is that it hides the selected time unless you click the clock icon at the bottom. I think Buffer's approach is more intuitive because you can see the date and time, and adjust either one easily. But thanks for the link!

[Eonasdan]

@jeremyhaile I've added a side-by-side mode into staging branch. Note that the staging branch is in testing with some recent fixes.

[jeremyhaile]

@Eonasdan ah - nice. Does the side-by-side mode adjust ok if the user is on mobile?

[Eonasdan]

@jeremyhaile actually, I haven't tried it on mobile. I know people are complaining that the picker has trouble being dismissed on some mobile devices if the time selection is also enabled

[jeremyhaile]

@sunils34 @nieldlr @joelg Any update on the time frame for open sourcing your fork? I understand if you don't have a timeline, but any estimate would help - as I'm trying to decide on switching to a different date/time picker, customizing one myself, or waiting for your project to be open sourced. Appreciate it!

[nieldlr]

Hi @jeremyhaile, terribly sorry for the late reply here! I'm going to be working open sourcing our fork this week. So, you can expect to see it out soon! Most likely by the end of this week.

[jeremyhaile]

@nieldlr That's great - thank you!

[nieldlr]

Hi @jeremyhaile, I took a look into open sourcing our fork, but I realized that our version is quite a bit behind eternicode's latest. What do you think I should do? We can open source our current version, but it might have some functionalities missing, such as the multidate selection & orientation features (along with some refactoring I saw in eternicode's latest). We can spend the time to update it at a later stage.

The other option would be that I take the time to get our's updated to the latest and give it a nice testing run before open sourcing. This might take a bit more time!

What do you feel? My feeling is that perhaps we release our version as is, and let the community decide what they are missing from eternicode's latest, then we update it based on that? Seems like a nice lean solution :) I'm totally cool with any decision though! Would love to give back as we've received a lot of value from using this plugin!

Let me know! Looking forward to releasing this!

[jeremyhaile]

I'd vote to release it as is and then update it later. Or let the community submit pull requests to update it. Thanks again!

On Sat, Mar 15, 2014 at 12:55 PM, Niel de la Rouviere
[email protected] wrote:

Hi @jeremyhaile, I took a look into open sourcing our fork, but I realized that our version is quite a bit behind eternicode's latest. What do you think I should do? We can open source our current version, but it might have some functionalities missing, such as the multidate selection & orientation features (along with some refactoring I saw in eternicode's latest). We can spend the time to update it at a later stage.
The other option would be that I take the time to get our's updated to the latest and give it a nice testing run before open sourcing. This might take a bit more time!
What do you feel? My feeling is that perhaps we release our version as is, and let the community decide what they are missing from eternicode's latest, then we update it based on that? Seems like a nice lean solution :) I'm totally cool with any decision though! Would love to give back as we've received a lot of value from using this plugin!

Let me know! Looking forward to releasing this!

Reply to this email directly or view it on GitHub:
https://github.com/eternicode/bootstrap-datepicker/issues/29#issuecomment-37731038

[nieldlr]

Hi @jeremyhaile, terribly sorry for the delay!

Some good news! https://github.com/bufferapp/bootstrap-datepicker

Let me know what you think and if there's anything we can do make things clearer or help out on setting it up. Would love to smooth it over.

You're also super welcome to submit your pull requests & log issues. Thanks again for nudging us to open source this. We definitely want to start doing this to more of our code.

All the best,
Niel

[jeremyhaile]

@nieldlr We'll try it out and I'll let you know how it goes. Thanks!

[rchavik]

Added a PR #909 based on team bufferapp's changes.

[JNajera]

I made a fork based on @Eonasdan and @joelg take a look.
Hope it helps.

[korun]

@JNajera, link is broken.

[JNajera]

@kia84, my bad, link updated.

[heyallan]

+1 @JNajera

[korun]

Hmm, I don't like that this fork doesn't contain the original commits. :expressionless:

[liufengyun]

+1 for http://trentrichardson.com/examples/timepicker/ it uses slider to choose hours and minutes, elegant and convenient.

[sroe]

+1 trentrichardson timepicker: btw you can customize timepicker by trentrichardson so it use dropdown instead of slider, see examples for more customization options. So @gagarine's comment doesn't count as counter-argument anymore :smile:.

[nicinabox]

Hey guys, we just open sourced our datetime picker based on this project and Trello's UI.

Source: https://github.com/Zeumo/datepicker

[jeremyhaile]

@nicinabox I really like the design of your date/time picker. Unfortunately, you have dependencies on lodash, handlebars, moment, and bootstrap-datepicker. For such a simple widget, this is a ton of dependencies. We don't currently use lodash and handlebars, and don't want to add them just for a date/time picker.

Any chance you guys are planning to reduce your dependencies? I think that would allow you to get wider adoption.

[nicinabox]

Thanks @jeremyhaile. You're right, lots of dependencies for something fairly simple. All of those dependencies existed already in our application, so the overhead was pretty small for us. If there's interest in trimming the fat I suggest making an issue over there so there's more visibility within the company and I'll see what we can do :)

[Azaret]

Time fly.
But this plugin is no dead, I hope not much people lost hope.

@acrobat @hebbet I think this could be a must for some 2.0 release.
bootstrap-timepicker looks quite pretty and the most completed imo. Also since it is not maintained anymore, if @jdewit agrees we could somehow merge it in.

UI speaking we can keep what we have when we only need date, and keep timepicker's one when only time is needed. When needed both, I think simply appending the timepicker at the bottom should do the trick.

Code-behind speaking, it will need indeed some work, we should see where to place this in the roadmap towards the other hundreds issues.

What do you guys think ?
(Yes now @eternicode has opened this project I'm determined to not let it die :P)

[acrobat]

Yes that's definitely a feature we want to have, possibly in a 1.X release if we can finalize this feature! Otherwise it's indeed something for 2.0

[Azaret]

I wrote that before getting like page 3 of the issues (there is too many tickets here) so I found the PR already made.

[Dimas-sc]

Having the date-range feature with time pickup functionality would be a killer feature. Hope we can see this implemented soon.

[bennybee]

+1 to this
JNajera's looks the easiest to use (least clicks)
Frustrating that the eonasdan version only shows you the selected time once you open the time picker

[bennybee]

The UI implementation of Date/Time in the 'Datatables' plugin would be ideal for me:
https://editor.datatables.net/examples/dates/datetime.html
(click a row then 'edit)