Date range in github search code

[david26694]

Select Topic Area

Question

Body

I would like to use date ranges when using github search for code. For instance, this returns all pandas imports in github:

https://github.com/search?q=%22import+pandas+as+pd%22&type=code

I'd like to return all pandas imports in github with either of the two filters:

• File last committed in a certain date range
• File first committed in a certain date range

Is this in the roadmap?

[look]

Thanks for your question @david26694. Our new code search backend does not support date filtering. In order to prioritize this, it'd be useful to hear more about your use case for wanting to find all the pandas code on GitHub within certain date ranges.

[fulldecent]

All GitHub. Using it to discover projects

[LiteBrite82]

We cant filter code by date. Maybe we could try coming at it from a different angle?
Im not familiar with PrestaShop; do they have any proprietary file names? something unique to their code base?

[LiteBrite82]

my typical goto solution for this type of search is search the commit history. Though that depends on how detailed the commit messages are (the commit search only searches for terms in the commit message and authors etc..)

[LiteBrite82]

example: https://github.com/search?q=_PS_MODULE_DIR_&type=commits&s=committer-date&o=desc

[fulldecent]

Yes, this order is good

[david26694]

I'd like to use github search to monitor usage of a library I developed. Currently I do this:
https://github.com/search?q=%22from+cluster_experiments%22&type=code
and I get the total number of imports. However, I can't monitor number of files using it since last week or last month.

[look]

Thanks for following up. I'll let the team know your feedback.

[modcruz]

Thanks for following up. I'll let the team know your feedback.

Hi @look , Any update on this requirement??

[ryboe]

We're debugging a very strange issue that's hard to reproduce. The only thing we know for certain from our logs is that it started at a certain time two days ago. It would be awesome if we could search for all commits in our org from around that time.

Here's what I'm imagining:

org:mycompany.com after:2024-04-21T09:00:00 before: 2024-04-21T08:00:00

Thanks for considering this feature.

[look]

Commit search features committer date and author date (Git records both dates) filtering, check out the documentation.

You example would be something like this:

org:mycompany committer-date:2024-04-21..2024-04-22

[kevinpeno]

Please consider adding support for the Duration/Period syntax of ISO 8601. This would allow saved searches regardless of the current date. I stumbled upon this limitation today due to wanted to search for "help wanted" issues/PRs, but not ones so stale that it wasn't worth looking into. I'm sure I could come up with a number of everyday use cases for organizational code as well with enough effort.

Example use cases:

Last updated greater than one year ago today:

• Current: updated:>2023-10-13 (must update date every single day, can save, but not really useful)
• Expected: updated:>-P1Y (implies "greater than one year ago from today", will always work if saved)

Bob implemented that fix within the last month, I'm sure of it

• Current: user:bob author-date:>2024-09-13
• Expected: user:bob author-date:>-P1M

What changed in the last 24 hours to cause this outage

• Current: author-date:>2024-10-12 (must manually create each time)
• Expected: author-date:>-P1D (can save for fire drills)

Complex use case for saved PR/issue search (technically what I tried to accomplish today)

• Current: is:public state:open label:help-wanted,helpwanted,help+wanted,help,hacktoberfest updated:>2023-10-13 (could save all except updated since portions and need to change daily)
• Expected: is:public state:open label:help-wanted,helpwanted,help+wanted,help,hacktoberfest updated:>-P1Y (could save and use whenever)

Arguably, if you considered this proposal, you could get rid of the <> and .. syntaxes in favor of Range/Period (P) and Time Interval / syntaxes, possibly simplifying the parsing of the parameters since these are standard ISO capabilities and should be supported by date parsing libraries. Things then might look like this:

Period: updated:-P1D
Interval: updated:2024-10-12/2024-10-13

Note: -P is via ISO 8601-2:2019(E) (1, 2, Library of Congress Spec (similar))