Define the Problem Better
Is the issue whether there is sufficient overlap of "core hours" for members of the team to communicate, or is the issue that you have team members with different levels of skill and/or productivity? You mention both issues, but you can't solve for everything simultaneously.
The idea of core hours dovetails well with the Scrum and XP practices of "sitting together." While it is considered a practice and not a methodology requirement, it is worth listening to what the proponents of the methodologies have to say about the practice.
"Sit Together" predicts that the more face time you have, the more humane and productive the project.
Beck, Kent; Andres, Cynthia (2004-11-16). Extreme Programming Explained: Embrace Change (2nd Edition) (Kindle Location 893). Pearson Education (USA). Kindle Edition.
The idea is that a certain amount of face-time among team members, while not strictly required (and sometimes counter-productive in certain environments or for introverted team members) is still generally considered a generic best-practice because it enhances the level of teamwork through non-verbal communication, as well as fostering a sense of cohesion and allowing team members to pick up additional information through osmosis.
A healthy agile team works together in high-bandwidth, high-quality communication.
Adkins, Lyssa (2010-05-18). Coaching Agile Teams: A Companion for ScrumMasters, Agile Coaches, and Project Managers in Transition (Addison-Wesley Signature Series (Cohn)) (Kindle Locations 2459-2460). Pearson Education (USA). Kindle Edition.
The amount of overlap required to implement "core hours" is somewhat fluid, but in my own practice I've generally found that the core hours of 10:00am-2:00pm work well for most teams. It allows the early birds and the night owls to overlap for at least a few hours every day, while still providing plenty of flex-time so people can avoid traffic and avoid working against their natural biorhythms.
Of course, if you implement core hours at all, it's important that any all-hands meetings (e.g. daily stand-ups or Sprint Retrospectives) be scheduled to start and finish within the bounds of the core hours. This isn't really hard to do, but it's something that one should keep in mind if your team values any sort of consistency.
Skills and Productivity Have No Relationship to Wall-Clock Time
If you are managing an agile project, life is simple. Things are either "done" or "not done." As long as the team as a whole is meeting its commitments every sprint, and the team retrospectives don't indicate that there is dead wood on the team, then how people organize their own work (and by extension, their own work hours) should be fall under the M.Y.O.B. rule.
If Alice handles her fair share of user stories, helps others on the team as needed, and even occasionally finds time to pull additional stories off the backlog, why on earth would you care if she only works four hours a day?
On the other hand, if it takes Bob 8-10 hours per day, every day, to keep up with his fair share of the user stories and he never finds time to pay down technical debt or pull additional stories, there still isn't a problem unless:
- Bob can't mind his own business about how other people work.
- Bob is being allocated more than his fair share of the stories.
The first is a social issue, in which Bob is the toxic element. The second is likely a process issue--one that needs to be addressed by the team in a retrospective, or by the Scrum Master by bringing it to the team's attention.
In other words, as long as both people are pulling their weight, adding value to the team's overall efforts, and ensuring user stories meet the team's definition of done, then any "problem" is illusory. Such illusory problems are often holdovers from a management style that values high individual utilization over system throughput.
Always, always make sure you understand the root cause of a problem. In some rare cases, you may actually have a lazy or unproductive team member. In other cases, you may just have a busy-body on the team who can either be coached or voted off the island. Finally, the problem may just be a process that values perceived effort more than actual results.
Measure the productivity of your team as a whole rather than by micro-managing individual work habits, and define the validity of the overall process by its throughput. If the majority of your sprints are delivering tangible value and user-visible features, then don't break a process that's clearly working successfully!