A couple of notes:

• The only reason it won't let you have a one-day project is because of front-end validation, which at some points tries to enforce a minimum of 1 week. I don't think that's necessary for Wiki Ed's purposes any longer, because of other changes in the course creation flow that make it unlikely for users to simply skip setting dates altogether (and end up with a course that starts and ends on the day it was created).
• The date handling — for the calendar widget as well as the calculations of which days a course meets — has some bugs related to courses that start and end the same date, which I just noticed when trying this out. (It's possible to set the dates like that after the course is initially created.) I'll file those when I get a chance. In general, our front-end date handling is pretty messy — and also relatively expensive, in terms of javascript processing. There's a lot of room for improvement in how the dashboard frontend does date-related calcuations.
• There are no major blockers to making the metrics limit calculations to a datetime range (instead of just a date range, as now). But, do we really want to limit metrics calculations to (for example) the five hour window between the start and end of an event, and not count anything participants do the rest of the day? Is that how programs currently report outputs for things like an Edit-A-Thon?

But, do we really want to limit metrics calculations to (for example) the five hour window between the start and end of an event, and not count anything participants do the rest of the day? Is that how programs currently report outputs for things like an Edit-A-Thon?

It is how we ask that global metrics are calculated (for an editathon or any other program). This also becomes a bigger issue in writing contests, which can be cutthroat up to the deadline, and judging could be messed up if submissions after the deadline are included.

I know that the WMF puts pressure on groups to wrap up events within a day but I do not think this is a thoughtful way of measuring impact or an idea with community support.

The reason for the date tracking is a desire to prove a relationship between event funding and event impact. Right now, I do not believe that enough events are funded to justify trying to establish a workflow around establishing diligence in giving event grants. It is almost certainly true that more money is invested in reviewing events than actually having events, and until it happens that the money spent on direct impact exceeds money spent on administration, it is hard for me to understand why the natural workflow ought to be impeded or restricted for the sake of understanding budgets on the scale of coffee and maybe community center rental.

If I were designing this, I would make "tracking dates" an easy to change field. It is important to get attendee names, but it can happen that not until long after the event do the organizers know what dates they want to claim as impact dates. It could be 24 hours, or it might be a week, or more likely (especially with new users who signed on during the event) they might wish to claim years after the event. Wikipedia's recruitment period is often years, and conversion sometimes can be traced to particular events years before the conversion.

This sounds like 2 separate tasks:

• Allow programs to be only 1 day long (a simple fix to the existing code)
• Add support for start and end times (new interface and some refactoring of existing code and interfaces)

@Bluerasberry: I'm afraid I don't understand how your comments are related to this bug. What does "establishing a workflow around establishing diligence in giving event grants" have to do with letting people set the time period for their event to less than a week? A lot of 1-day events don't even get grants. Why should we force them all to be at least a week long?

Also just created:
T140306 - Add support for setting the time zone of a program

I like that wireframe!

This may be helpful for the styling: https://dashboard.wikiedu.org/styleguide.

Here's root of that UI: https://github.com/WikiEducationFoundation/WikiEduDashboard/blob/master/app/assets/javascripts/components/course_creator/course_creator.jsx

Note that default_course_type === 'ClassroomProgramCourse' is the basis for switching between the course-oriented version (for Wiki Ed) and the event-oriented version (for the programs dashboard).

These values would also need to be editable from the Details component (and should not show up for the ClassroomProgramCourse type). See https://github.com/WikiEducationFoundation/WikiEduDashboard/blob/master/app/assets/javascripts/components/overview/details.cjsx

Don't know if it's worth mentioning but took a look at the design suggested and thought about it: start and end date/time are not always in the same timezone. Like CEE Spring in Ukraine this year started by EET (UTC+2) and finished by EEST (UTC+3) due to DST. So perhaps hidden by default but there should be a separate timezone field for the end point accessible too.

In T125546#2611674, @Base wrote:

Don't know if it's worth mentioning but took a look at the design suggested and thought about it: start and end date/time are not always in the same timezone. Like CEE Spring in Ukraine this year started by EET (UTC+2) and finished by EEST (UTC+3) due to DST. So perhaps hidden by default but there should be a separate timezone field for the end point accessible too.

Ah, working around DST is very tricky! Timezone support is next on the list with T140306 and we'll definitely have to keep this in mind. Thanks

So I toyed around with several UI ideas and found this to be the most intuitive and aesthetically pleasing:

This just makes the hours/minutes a dropdown, meaning we can cut corners and not have to write validations, etc, and I think it looks quite nice. Wanted to run this by you all before I get into more coding. Note for some users AM/PM may not be desirable. We could add some i18n checks to determine whether to show it, but I figure 24 hour works just as well. @Ragesoss @DannyH what do you think?

@MusikAnimal: I like this. If we're going to ship this before adding full timezone support, though, then we need to add some explicit indication that the time should be specified in UTC.

In T125546#2613228, @Ragesoss wrote:

@MusikAnimal: I like this. If we're going to ship this before adding full timezone support, though, then we need to add some explicit indication that the time should be specified in UTC.

Hopefully we can ship both in tandem, but I suppose that depends on how badly people need the start/end times and the work involved in adding timezone support. I see we're using moment.js, maybe we could look into moment-timezone as well, but at the cost of 2.7KB of JavaScript.

Our javascripts are pretty big already. I won't sweat an extra 2.7KB. But we'll definitely need to let the user set / change the timezone explicitly, even if moment-timezone is helping us out by setting a default based on client-side timezone inference.

@Ragesoss I've created a PR for what I have so far, just to illustrate my approach (this is far from a working prototype): https://github.com/WikiEducationFoundation/WikiEduDashboard/pull/951/files

Basically everything will be moment objects, which we need to convert when we fetch the data from the server. With that we should be able to safely do date manipulations and have it all be saved in the same field in the database. Any feedback is appreciated. I did something very similar at my last gig and it worked for us, also using moment/React/Rails/etc.

Also I'm amazed it only took a few hours before there were conflicts with master! =P I was thinking it might be wise to partition this task into smaller deployments, perhaps starting with the database migration. That seems like the most risky to me... The date to datetime seems safe, we just need to backfill end dates to be at 23:59:59 so they are at the end of the day. Once we have that cleared up, we can do some backend work to put everything in place before adding the time pickers to the UI.