It might be better to say "changes in state are time".<p>This is a deeper understanding of what time is than the common one we have... but... since "the common one we have" is the result of living in a universe that is absolutely constantly pounding state changes into us every Planck-time of our lives, and I don't know about you but I'm not building anything that I expect to exist in some sort of ontologically different state, you can do rather a lot of work with the "intuitive" concept of time. Even complicated server communications which are fast enough that the fact that relativity bans "simultaneous" becomes relevant can be understood just fine in an intuitive framework.<p>I do find it helpful to conceive of time as "state changes occurring" for a particular case, though, which is multithreaded programming. It is helpful to conceive of threads as "perceiving" time not as ticks on a clock, but changes in the state (which can be to a first approximation be 'lines of code executed'). From this point of view, threads do not experience time as a clock ticking onward, but as "a particular value that exists but only when they look". That is to say, if a thread "consults the clock" and determines that it is noon on Jan 1st, it can be helpful as a programmer to understand that that does not particularly mean that three lines later, it will be noon on Jan 1st. Arbitrary amounts of universe-time can progress between any two lines of code. Threads really relate to each other not across universe-clock time, but by what observable effects other threads cause on them, and <i>only</i> on what observable effects other threads have on them. In principle, two threads that cause no effects visible to the other are essentially running in different universes. This is a place that a mathematical mindset can really help.<p>But, again, this is just a sort of helpful thing for relatively advanced mental modeling, but you can get a long way just based on assuming a monotonic universe-clock.<p>This is why I assert, with some vigor but without much persistence (since it's obviously a <i>massively</i> uphill battle), that a clock-simulating library really should not be based on assuming threads will witness a monotonic universe clock, and a clock-simulating library ought to make it possible to test that a task nominally scheduled to come after some other task actually runs to completion before the first task even starts, because that can happen in the real world. In an imperative language, you can assume that one statement within a thread will follow another, and that the external threads you can see are also operating in that order, but the slip <i>between</i> those "ticks" can be arbitrarily large.