[SiempreViernes]

Yes, you can easily create a constant rate counter, but no: it wouln't keep time.

To keep time you do care about the position of the sun because that defines the time of day, humanity's base for the experience of time.

If you will never care about what the time is in your application, by all means, count clock cycles, otherwise: UTC is the standard for keeping time.

[hakfoo]

That brings up an interesting question: Is that the current, best, or only basis for time?

I'd argue that many relevant time concepts are more framed by social conventions than the sun.

Most of us are more interested in concepts like "when does work start", "lunch time", and "when the store closes", than "when does sunrise occur" these days. In a pre-industrial society, those might be closely synched, but less so today.

[SiempreViernes]

Those are important events in the day, but they don't serve as a basis for defining time.

When does work start? Well, it starts when the hands on the clock points just so, there really isn't any more fundamental definition. But clocks are tools for measuring time, they don't define it.

If your clock slows nothing particular happens to other clocks, and time marches on unslowed. But sunset will bring night whether you notice it or not, and that's a pretty definite marker of the passage of time.

[gizmo686]

Time is a well defined physical property that has nothing to do with the posistion of the sun.

We already have time localizations, time zones, daylight savings time, and leap days all handled by layers above UTC (actually, all in the timezone layer). Leap seconds should be part of that layer, not the UTC layer.

Once we get into relativistic effects, there is more complication to the lower layers, but we (mostly) don't need to deal with that.