I don't know. From my point of view the major use case for the clock is synchronizing activity with other people. It is convenient for this as a common referenc

I don't know. From my point of view the major use case for the clock is synchronizing activity with other people. It is convenient for this as a common reference. It can be used for other purposes but a lot of those are "bloat" features on the notion of time. Before we had computers to keep track of time and give us notifications there was a good need for us to know what time it was, so we could manually track our synchronized events - automation or outsourcing it was prohibitively expensive for a lot of purposes. Now we can move most of that clock tracking to easy, cheap, and convenient tools and live a more event driven lifestyle without losing the major benefits of worrying about what time it is. Sure there are still a few times it becomes a thing - scheduling meetings for later, figuring priorities based on deadlines, wondering if i have enough time to get into something before scheduled events, but outside these planning moments, most of the concern need no be there. Here is the really neat thing IMHO - as we all move into this event driven paradigm, the clock may not even be the big source of synchronization.. A lot of my meetings are not decided because "this is the perfect time for it", but on "we are all available". Ok great, that means most of my meetings are pretty fungible on when they can happen. So why not put a flag on those meetings, with a reasonable priority and set of boundaries on specific times... then have a piece of software that learns my activities to figure out when I am most interruptible, and communicates with other meeting participants to just interrupt us all for the meeting at good times? Yeah its NP hard, but for small groups not that expensive anyway. It certainly helps manage the rift between the maker schedule and the manager schedule.