Closed m-mohr closed 1 year ago
makes sense. as already noted: I don't think this will have practical impact at the moment.
Also note that we already could introduce the new date_difference
process in the 1.x branch and do the breaking 2.0 changes later
@soxofaan True, but 1.3 and 2.0 are pretty much 2.0 now, I don't think we'll get to an intermediate 1.3 release honestly, but instead directly start with 2.0-beta/rc.
I don't think this will have practical impact at the moment.
Can confirm this for our backend as our process implementation (for those) didn't support date formats from the beginning.
This is a proposal to simplify the comparison processes. The discussions in #394 lead me to the conclusion that we may not want to handle date/times in so many processes specifically so that issues can be solved in some central places rather than spreading them into so many processes. Also, the old implementation was a bit suboptimal in that you had to parse the inputs first to detect whether the values are temporal values, potentially making the comparisons slower than needed. Most use-cases can likely be solved with a new process such as
date_difference.
.This includes a breaking change for the comparison processes. The impact is assumed to be low as most date/time values would usually come from labels in timeseries, but label support seems very limited in back-ends right now. For
between
back-ends can choose to still support the old behavior.Looking for feedback.