Think in Five-Day Cycles
You're thinking in seven-day cycles for some reason. You may have a specific use case for this, but I would consider it unusual to plan this way. As a general rule, Sprints are based on single teams, and a team usually plans around 40 hours per person during each week, and five business days per team.
So, if you're planning one-week Sprints, you could start on a Monday, end on a Friday, and then start again on the following Monday. This is a typical cadence, and certainly the most common.
Scrum teams that don't decouple delivery from deployment might prefer not to deliver on a Friday, because in such shops there may be no one to tend production over the weekend immediately after new features have been rolled out. In that case, they may prefer to deliver earlier in the work week. This gives newly deployed code a couple of days of "burn in" before everyone leaves for the weekend.
In this type of cadence, starting each Sprint on Wednesday and ending on the following Tuesday (along with the associated deployment) leaves three business days for burn-in and urgent bug fixes. You could also start on Thursday and end on Wednesday, or (for teams that only allocate half a day each for planning and review/retrospective ceremonies) start and end on the same day each week.
The Whole Thing is an Anti-Pattern
In case it isn't obvious, all the atypical cadences above are really anti-patterns. They are trying to work around defects in staffing, planning, process, tooling, or organizational politics by routing around the problem rather than resolving it.
Truly agile teams should decouple delivery from deployment, and the Definition of Done should include sufficient quality assurance and continuous integration testing to assure that breaking changes aren't likely to make it into production. If these things are done properly, there's no reason to have weekly Sprints that are out of sync with the Development Team's work week.
In close to two decades of agile implementations, I have yet to see this type of delivery cycle serve any purpose other than to cover up an X/Y problem of some sort. If you think you have to do it, then the organization is probably less agile than it imagines itself to be.
If you must do it, then adjust your delivery dates to fit somewhere within the middle of the work week where it is least likely to be disruptive to developer flow. As a singular example, delivering on a Monday is usually a spectacular failure for most teams that break for the weekend, although your mileage may certainly vary. Even when following an anti-pattern like mid-week delivery, it's usually best to optimize for flow and shorten Sprints to fit within a predictable weekly cycle.
The Scrum framework optimizes for predictability. Select odd or unpredictable Sprint lengths or unusual delivery cycles at your own peril.