I’ll add that generally, even though I have limited insight into how time series are used, I’ve always felt the need to “defend” null/the “unknown” setting. It’s a vital piece of information in many situations, but lots of people seem to want to suppress it because they find it troublesome to deal with.
The result of doing such is almost always just making things worse though, because when something is truly unknown, the only way to avoid expressing the unknown, is to “lie” and use some value that you have no real reason to claim. Sometimes, values way out of what would otherwise would be possible is used to indicate “unknown” (like -1 for things that can only be possible or “” for a string value), but how is that better? Instead of using the well established, known “unknown” value, people must know what value has been chosen to replace it in each particular situation.
I love null, and to me, it was a “revolution” when I first met it when moving from Basic to Turbo Pascal. I’ve used it extensively ever since, always feeling a bit of “joy” as I know that, not only is it correct (it’s a “value” you can use that’s outside the range of “valid values”), it’s extremely cheap to use. You can use it without really considering the performance impact.
If it’s even remotely possible that “unknown” is an actual state, it should usually be included in what’s possible to express.
No you do not have to represent gaps in OH because you do in SQL.
OH is the use case, SQL is a base tech.
OH persistence isn’t SQL or meant to provide all use cases SQL must be able to handle so argumenting that way doesn’t apply.
Funny you take this as an example - I’m programmer of a commercial OH based EMS, doing right that stuff all day long.
You as the programmer have to validate the tariff data you retrieve (or your binding does for you, actually).
So if there’s a value missing, either you trust the binding to do the right thing ™ for you (i.e. determine which price to use when you have no data) or, if you parse that manually, ensure you have a value for every 15 mins interval, i.e. the API-provided list has no gaps.
But that’s an edge case as you know there has to be a new value every 15 mins right at the beginning of the interval. In most other OH scenarios, it’s not like that, item update intervals vary.
The bottom line: this has nothing to do with how the values are or should be stored in TimeSeries.
