Tyler Helmuth

Yes, OTTL (TQL) supports setting the timestamp field today, although probably not intelligently (you have to supply a hard coded value essentially). But a more intelligent function could be added.

@atoulme at the moment the transform processor supports setting the time like: ```yaml transform: traces: queries: - set(start_time_unix_nano, 100000000) - set(end_time_unix_nano, 200000000) ```

We don't have have the concept of addition or subtraction in the grammar yet, but it could be added.

@simpli-laban @labaneilers If the change affects users we'll do a Minor bump (since we don't have a Major version yet). But if the change doesn't affect anyone we could do...

@labaneilers please handle merge conflicts (its probably the chart version)

@dmitryax I am curious if any of the metricstransform processor scenarios require individual datapoint interactions?

@dmitryax could those be handled by a "datapoint" context tho? Or are you saying that while interacting at the "metric" level we also need to be able to mess with...

I'll need to keep iterating on how to handle this then. If we need to be able to interact with an individual DataPoint at the same time (with in the...

@dmitryax @bogdandrutu looking through the metricstransformprocessor's current functionality, I think it can be broken down into these 2 separate OTTL Contexts | Operation | Example (based on metric `system.cpu.usage`) |...

@dmitryax in **Approach C** you have `func (ms Metric) GetGauge() Gauge` but also `func (ms Metric) Sum() Sum`. For gauge, did you mean `func (ms Metric) Gauge() Gauge`?