There are two equivalent definitions of monad: one in terms of (>>=) and one in terms of fmap and join. Given (>>=), we can define join and fmap as
join :: Monad m => m (m a) -> m a
join x = x >>= id
Given the join and fmap, we can define (>>=) as
(>>=) :: Monad m => m a -> (a -> m b) -> m b
x >>= f = join (fmap f x)
This is why some other languages like Scala call (>>=) flatMap: it's the combination of flattening (join) and mapping (fmap).
Personally, much of the time, I find join more intuitive for a given monad than (>>=), but (>>=) is more useful for everyday code so it's included in the class by default. Recently, there was a move to add join to the class so that you could choose which one to implement, but that ran into some technical difficulties and had to be postponed.
As far as time-varying code goes, you were right in your intuition that it's closely related to FRP. You have, in fact, come up with a type similar to events in classical FRP—an accomplishment on its own! I found Conal Elliott's "Push-Pull Functional Reactive Programming"[1] to have a good overview of existing ideas in this vein, including a discussion of the relevant Functor/Applicative/Monad instances.
My understanding is that while the monad instance for this temporal type is well-defined, current libraries do not implement it for performance reasons. It's difficult to enable this sort of logic without exposing potential memory leaks, which make practical programming in the style significantly more difficult. But the conceptual ideas are all entirely sound!