That's actually a bad example because 17 is always going to be the day as there is not a 17th month.

that's the result of this particular query (just an example) with #17/06/2023# criteria. It should have returned 8 records with the same date. The SQL above is what access generated by the way

ISO Date Format

SQL always and only uses the US date format (mm/dd/yyyy).  It may be because the SQL standard was invented in the US.  If you use dd/mm/yyyy format in the SQL, Access can still correctly interpret it, but only if it's unambiguous.  If you write #31/1/2025#, Access can unambiguously interpret it as Jan-31-2025 since there is no month called "31".  But if you write #11/2/2025#, Access will always interpret it the American way, Nov-02-2025, because "11" is a valid month.

If you use two-digit year, there is one more scenario to watch out for.  If you write #31/1/25#, Access will not see it as Jan-31-2025, but Jan-25-2031 instead, because Access will think it is in ISO date format yy/mm/dd.  So, always use 4-digit year.

Even if you use an European version of Access, it will still force you to use the US date format.  The query designer accepts the European format, but the SQL statement itself (the only thing that counts) always has US dates.  This is not to give non-US people a hard time.  It's done because it's necessary.   The SQL is text-only, and it carries no information on which country the author of the SQL is from.  So there is no way to "switch" between two date formats.  So a fixed date format has to be used for everyone on Earth who use SQLs.

If you think this sucks, many people think so too.  That's why some database tools, such as Microsoft's own Power Apps, do not use SQL at all to query databases.