I certainly agree that there's no reason that the "Time" type used in TimeDag has to be a DateTime, and it's been at the back of my mind as a generalisation [1] that may be wanted at some point. It wasn't immediately required for our use-case, but good to know that there is interest in having this feature!

Is a generalisation of Block sufficient for your needs? I'm not completely against [3] doing something like this in isolation if it is useful for you. However, on its own it wouldn't work nicely with the rest of TimeDag, and calling block_node on it may lead to unhappiness at some point when evaluating the graph [2].

Generalising the time type everywhere is certainly possible, but is probably not a small task (it requires adding type parameters in many places — at least to Node, and NodeOp & all descendants — and we may need to specify a TimeDelta parameter in addition to just Time)

complexity when mixing Blocks from multiple sources

Yep this is a concern. My gut reaction is to simply not support combining nodes with different time types (since this could indicate a more fundamental incompatibility — especially if permitting time-types beyond AbstractDateTime), but maybe we could.

[1] In fact, I wouldn't stop at AbstractDateTime :) Any type that implements basic comparison & addition should be usable — e.g. using a plain Int64 should be possible, although there's a few API details that need to be considered. When specifying a timedelta window to functions like mean, currently this will take any TimePeriod and convert to Milliseconds for internal use. We'd probably need a little wrapper type to avoid confusion with this method for the same function, and similarly elsewhere.

[2] Internally, each run_node! implementation will create a new Block that uses DateTime times. So, you'd lose time precision when evaluating, and there could be worse consequences as a result (due to the fact that, after precision loss, you may end up with duplicated timestamps — these aren't permitted).

[3] It's a step in the right direction — but my concern is that it could lead to confusion, since they wouldn't be supported by the rest of this package.