Month/Year picker

[tymees]

As a small enhancement it was requested that the startdate could be a month/year picker instead of a day/month/year picker; the exact day is not needed information and it might reduce stress for the user ;)

[tymees]

It's probably an issue for DSC, but registering here for now as it's not a priority for now. So more an issue such that we don't forget

[miggol]

It's nice that projects can span multiple repositories. If we make a projects for DSC we could link to this issue either way.

[tymees]

Not a bad idea; i probably should organise the issue tracker for DSC better anyway

[tymees]

So, just some design questions:

• Would one want one input field, or is one for date, one for year good enough?
• Do you really want to compare full dates with month-year dates?

[miggol]

Would one want one input field, or is one for date, one for year good enough?

If we're talking about fields on the DB model, then just the one would surely be preferable. But if we're talking about frontend stuff then either is good. The screenshot you sent was nice.

Do you really want to compare full dates with month-year dates?

It's definitely a nice to have. My use case would be logical correctness for determining "studies that have yet to start" and "studies that have finished". The former is supported with day=1 but the latter would require additional code that I think would best belong on the field side of things.

Not a deal-breaker though!

[tymees]

If we're talking about fields on the DB model, then just the one would surely be preferable. But if we're talking about frontend stuff then either is good. The screenshot you sent was nice.

Yeah in the DB its just a datefield; the frontend has both options available as widgets

It's definitely a nice to have. My use case would be logical correctness for determining "studies that have yet to start" and "studies that have finished". The former is supported with day=1 but the latter would require additional code that I think would best belong on the field side of things. Not a deal-breaker though!

The way that the model field works is that any date(time) passed to it will be transformed to a date with day=1. (Basically, a floor() for dates?) Even if the date in question is a filter parameter and not a field value.

So, a field with 'august 2023' as its value will still return on a query with the filter field__gte='2023-08-22' (even though 22 is obviously greater than 1), as the actual performed comparison will be '2023-08-01 >= 2023-08-01'. (The same does not apply for comparisons done in Python, but as the model field will return a custom date implementation it's easy enough to do the same thing in the python comparison functions).

Thus, if your mind ignores the 'day' value when working with the field, it should be relatively 'natural' to work with. At least, I think so? Does that satisfy your requirements for comparison?

[miggol]

The way that the model field works is that any date(time) passed to it will be transformed to a date with day=1. (Basically, a floor() for dates?) Even if the date in question is a filter parameter and not a field value.

That's neat, and totally fulfills my requirements.

[miggol]

@tymees Is there any news on this matter? Just wondering for issue triage, no hurry right now

[miggol]

As an alternative, it has been suggested we could also make do with just a year picker.

[tymees]

As discussed, this widget is already in DSC develop/3.2-alpha.0