Putting this in here, but @MrX has requested that "please make it easy to use, with a slider or at least a calendar widget. It shouldn't require keyboard input and or multiple mouse actions." as a suggestion regarding this feature.

Honestly I won't be doing much page patrolling unless there's some way to start other than at the Newest or Oldest ends of the queue. I can't be paging endlessly to get to where I left off last time.

This shall be one of the foremost tasks in the development panel.Scrolling endlessly to get to where I left a certain-time-span back is ''dumb''.It has a huge benefit and there is no noticeable bane.

Any suggestions by the devs, please ask the NPP volunteers if the proposed solution is exactly what has been asked for before final roll out.

This may seem weird but I'd be happy with something that jumped me to a random starting date.

Either A): a jump to date button, or B) a calendar selection tool.

Requested here: https://en.wikipedia.org/wiki/Wikipedia:Page_Curation/Suggested_improvements#15._Jumpback
and here: https://en.wikipedia.org/wiki/Wikipedia:Page_Curation/Suggested_improvements#51._Allow_users_to_override_infinite_scrolling_of_the_feed

Growth-Team will not have time to work on this in the short-to-medium term.

Is there a reason that to must be required as opposed to just setting it to the current date if nothing is entered?

@Barkeep49 - If I understand correctly, are you asking if we can have the date selection for "To" set to the current date (as default) if the user does not input a selection? If so, I think that could be a good way to deal with that issue. I'll update the ticket.

Thanks @ifried that is what I was suggesting.

Change 533119 had a related patch set uploaded (by HMonroy; owner: HMonroy):
[mediawiki/extensions/PageTriage@master] Add ability to filter by date range in Special:NewPagesFeed

https://gerrit.wikimedia.org/r/533119

The standard format for date input fields is mm/dd/yyyy across different browsers (ex. Chrome, Firefox) so we have set this format as an instructional example. The results will be filtered according to a date range when the given values are submitted. If only 'from' date is submitted, pages that are newer or same as 'from' date will be listed. If only 'to' date is submitted, pages that are older or same as 'to' date will be listed.

In T167475#5449488, @HMonroy wrote:

The standard format for date input fields is mm/dd/yyyy across different browsers (ex. Chrome, Firefox) so we have set this format as an instructional example.

@HMonroy: I'm not aware of a browser that would use such an obscure uncommon date format (used by one single country) as a "standard" (did you mean default?).

Screenshot from Firefox 68, with "Edit > Preferences > Language > Preferred language for displaying pages" set to "en-us" followed by "en":

@Aklapper the date input field in your example is a custom OOUI one; the one being implemented in this task is a browser-native HTML5 one, i.e. <input type="date" />. These built-in date pickers are not customisable, and browsers are supposed to display the user's preferred date format — however lots seem to only use m/d/y, or treat any en-* locale as en-us. It's a bit of a mess.

Change 533119 merged by jenkins-bot:
[mediawiki/extensions/PageTriage@master] Add ability to filter by date range in Special:NewPagesFeed

https://gerrit.wikimedia.org/r/533119

Acceptance Criteria:

• Create a new section entitled "Date range" (in bold) in the filters view, which should appear below "Potential Issues"

The new filters appear on both "New Page Patrol" and "Articles for Creation".

In "Articles for Creation", it does not appear directly below "Potential issues", as in the mockup, but below "State".

• There should be one line/row for "From" and one line/row for "To" labels
• After the "From/To" labels, there should be an area in which users can input a specific date
• When the user has not input a date, they should view instructional examples of how this data should be input (i.e. dd / mm / yyyy), as seen in the attached mockup

What exactly is shown depends on the browser and locale, as is pointed out here T167475#5457664.

I tested on Chromium 73, Firefox 60 and 69, Edge 18 and IE11.

IE11 does not support the <input type="date"> element, so we just show a text box with the placeholder text mm/dd/yyyy. It is possible to enter dates in that format and also in yyyy-mm-dd, both being accepted and correctly interpreted.

• If the user inputs a date range, pages that fall under that date range (for creation) should only display in the search results.
• If the user does not input an ending date range (i.e. no "To"), the default date should be set to the current date.

It behaves as described in T167475#5449488, which fulfils these two requirements.

With the date filter applied, you can still change the sort order from oldest to newest (or vice versa), which just reverses the order of the articles in the list.

Filter applies to the article's creation date, rather than submission date (for draft articles submitted to AfC). This makes sense and appears to be what was asked for.

There is an odd bit of behaviour in Firefox 60, where the date input's close icons (x) remain on the screen after the filter flyout is closed. Firefox 60 is the ESR version, which Mozilla still officially supports. I don't know about us though.

@Barkeep49 @DannyS712

These changes should now be on production. When you get a chance, can you confirm if you're seeing these changes? Thanks!

Indeed. It's very exciting!

Looks good and works, except the pop-up calendars do not work as expected. Possibly due to the unique US date format instead of the international one?

@Kudpung Thanks for verifying that the update is live. Can you clarify what you mean about the pop-up calendar not working as expected? Thanks.

@Kudpung: If something does not work as expected, please follow https://www.mediawiki.org/wiki/How_to_report_a_bug and file a separate task with clear steps to reproduce, expected outcome, actual outcome, URLs, browser information. Thanks a lot!

I haven't experienced the bug, but I would hope if a bug can be verified about this new tool that it would be fixed not just left there to be fixed eventually.

In T167475#5524623, @Kudpung wrote:

Looks good and works, except the pop-up calendars do not work as expected. Possibly due to the unique US date format instead of the international one?

What browser and operating system are you using?

The date filters we added use a normal HTML date input tag. XTools does the same, see the date options at https://xtools.wmflabs.org/articleinfo. Do you see the same behaviour there?

The date format should respect your browser and/or computer settings, so I would check to make sure it is in the preferred locale (en-GB, en-AU, etc.).