Should 'zipper' protocol implementations return "dense" matrix or sparse?

[shanson7]

Problem description

Looking at existing implementations, they have lines like these which return values only for the "real" start/stop times, which might significantly reduce the memory used for series with high "churn".

However, functions like transformNull only seem to act on the set of values included, though theoretically the RequestStart/RequestStop Time should also be filled with NaN.

So my question is: Is this a bug in transformNull or should the zipper be providing "dense" values?

backend software and config

Custom in-house integration