Reduce date-time-entry to date-only-entry

Additionally to this github issue add date picker to forms #324 I wanted to discuss the following with you:
When creating a log entry, very often the time when this event happened doesn’t matter to me. E.g. I think it’s not important at which time of the day I plowed a field. However, I can image that there are events for which the time is relevant. (still I think we could argue about the necessity of “seconds”).
Would there be a way that the time fields can be skipped with e.g. a checkbox that says “do not track time” or something?
I know, I can just leave the time that is entered by default or specify 0:00:00 as time but still I saw this fields confusing less tech-savvy users.

1 Like

I agree, as a brand newbie 24 hours in to FarmOs I am finding the time setting unnecessarily detailed. Perhaps I am missing something obvious though. Most times I will be setting records to a date. Sometimes wanting to include the hour and rarely if ever the minute and seconds. I would also like to be able to set some items to only a month and date so they can repeat every year. Sort of related Why does /taxonomy/farm_season/ insist on year value for it to exist? Season stays the sama year in year out. With this arrangement the seasons set will only exits for one year then be out of date.

1 Like

I agree with both of you @PDorfFarm and @Logger! This is actually something I’ve been thinking about for YEARS haha. My thought was: have a bit of JavaScript that automatically hides the “time” fields, and sets them all to zero, with a little link like “Specify time” which shows them and lets you set a specific time if you want to.

Here is a similar discussion on GitHub: Timestamp widget hard to use · Issue #223 · farmOS/farmOS · GitHub

I added links to all three of these threads to the farmOS 2.x UI/UX roadmap, so we can tackle both together: https://www.drupal.org/project/farm/issues/3151246#comment-13752048

Regarding your other points, @Logger:

Most times I will be setting records to a date. Sometimes wanting to include the hour and rarely if ever the minute and seconds.

Agreed, time is usually not needed, but sometimes it is, so we have to support it. And behind the scenes all dates are stored as Unix timestamps, which include hours/minutes/seconds. So even if we aren’t showing time, we are storing it. Right now we’re just using a simple widget that comes with Drupal. So the next iteration would be to improve on that to make time optional, like I described above. If anyone wants to tackle that in farmOS 1.x be my guest! I plan to tackle it myself in farmOS 2.x.

I would also like to be able to set some items to only a month and date so they can repeat every year.

Ah so you might be interested in: https://www.drupal.org/project/farm/issues/2962368

Sort of related Why does /taxonomy/farm_season/ insist on year value for it to exist? Season stays the sama year in year out. With this arrangement the seasons set will only exits for one year then be out of date.

The “Date range” fields in “Season” terms are optional, and are not actually used anywhere in farmOS. We may remove them entirely in 2.x. So you can just ignore that and use Season terms however you’d like. Personally, I make a season for each year (eg: 2018, 2019, 2020) - that is sort of how they are intended to be used, so that you can more easily filter down Plantings that are part of a given season.

Hope that all helps/makes sense!

1 Like

Thanks for the response. So more practical time/date entry is planned at some point which is good. Can put up with the current arrangement knowing that it should improve eventually. Also the fine time granularity provides the means to sort items chronologically which can be useful sometimes.

Thanks for the explanation of seasons. I really have little use for them anyhow.

Do you know if event duration has been considered? So for example sheep shearing may run from Feb 1 to Feb 12. It a regular calendar one could create and even with a 12 day duration. I suppose in Farmos one could create two events Shearing Start 2/1 and another Shearing End 2/12, but it would not show in calendar as a contiguous event.

1 Like

There has been some discussion around it, but generally other approaches have been adopted instead. Generally I use logs to represent when something is “done” (so the “end date” of the activity). And if something takes more than one day, I will often actually create multiple logs, because that will more accurately reflect my actual activities. But it’s really case-by-case and you can decide what will be most useful in the future when you are looking back at your records.

For shearing, perhaps you could create a log each day, which references the individual sheep assets that were sheared that day. That might be overkill/too much data entry, but it’s an option.

Another approach that we are starting to build more features/ideas around is the concept of “Plans”, which are higher-level organizations of the lower-level assets/logs. So one idea might be to create a “Shearing Plan” that displays the “planned shearing date range” on a calendar, but then let’s you create individual logs within that to represent more specific details. Or maybe we make a more generic Plan type (like we are considerring for “Recurring Tasks” here: https://www.drupal.org/project/farm/issues/2962368)

Open to ideas! The shearing use-case is a great one for these kinds of considerations! It feels similar to “harvest window”, which we represent in the new Crop Plan module (in development) on a timeline, but still use individual harvest logs to record the actual harvests w/ quantities, etc.

The plans concept is a good one. What I have done is create a category in /taxonomy/farm_log_categories called “Planner” and I have assigned planned events like shearing to it. The image is an exert from a 20 year old list showing roughly what happens when on our farm. I am going to migrate its content into the event log, so the items display in the calendar when it is filtered to categery = planner.

As an aside it would be nice if the filters pane in is default collapsed view indicated if a filter was in place (Even just an asterix as in the label as in Filter *). I was wondering why my calendar was empty, thinking I must have deleted everything until I realised I had a filter in effect which nothing matched.