The important thing is that every single step when implementing this solution is quite simple and can be solved without not too much skills in electronics and programming.

But the number of steps involved means that the complexity adds up. A program containing 20 simple blocks is no longer a simple program unless the developer is skilled enough to properly isolate and document everything. A first year student does not have any real experience so the size of the problem would most probably make it overwhelming. And if they don't have a list already breaking the problem down into smaller steps, they would probably get lost quite quickly.

It is also important to notice that the limit to what is reasonable to do for a student will vary greatly depending on if they do it alone, or if they have a mentor that can help them when they are stuck. All it takes is often very trivial help. An unexperienced developer has a tendancy to view a problem from one specific point-of-view (normally the first one they got to think about) and can then stumble along on a very hard approach instead of noticing that a different view of the problem will convert it into a trivial problem. Another problem is that an unexperienced developer will treat every written (and thought to be working) code line as an olden-golide that must not be removed because of all the hard work involved. So they tend to add in more and more exception code just to tweak the original code, instead of considering a code rewrite. Because of this, they may fight with 100 very complex lines of code when they could have rewritten the logic into 20 lines of straightforward code.

Since a concept like this clock can be subdivided into simpler blocks, it could be done very early if the school decides to do the subdivision. The students could get 10 or 20 small assignments - one or two/week - that are later merged into more complex blocks and finally into a fully working clock.