I think there’s a key difference between what I suggest here and doing the entire thing in JavaScript: this is purely using JavaScript to set the initial time; the actual time keeping is done by the browser with a CSS animation, and thus it’s still a clock if JavaScript is unavailable or disabled, just one that starts at 12 o’clock instead of the correct time.
You can’t do it server-side because you don’t know the client-side time. The closest you could do would be to choose Swiss time for the sake of it (or UTC if you prefer).
Remember also that the clock will be out of sync if you set it server-side, because of latency between the server and client. This inaccuracy would doubtless besmirch the name of Swiss timepieces. Could be fun hooking into TCP and TLS negotiation to estimate latency in order to compensate in the animation-delay and make it probabilistically more accurate. Now that would be a fun article to read. I’m almost tempted to devise a way to do this myself. I suspect I couldn’t get the necessary information through my standard nginx reverse proxying arrangement and would need to serve the CSS from a different port so that I could handle the negotiation in a process of my own and observe the timings.
