[pkg/ottl] Support interacting with timestamps in at different precisions

[TylerHelmuth]

Component(s)

pkg/ottl, processor/transform

Is your feature request related to a problem? Please describe.

Currently, the OTTL only supports getting and setting timestamps with nanosecond precision. While this is semantically correct with the OTLP proto, there are times when interacting at such a specific precision is unnecessary and cause un-ergonomic statements.

For example, when comparing the duration of a trace (supported via math operations added via #15675), comparing the result in nanoseconds seems excessive:

transform:
    traces:
      statements:
        - set(attributes["tp_duration"], end_time_unix_nano - start_time_unix_nano)
        - set(attributes["time_bucket"], "fast") where attributes["tp_duration"] < 10000000000

Another use case where adjusting timestamps will be necessary is when adjusting for clock skew.

Describe the solution you'd like

This could be achieved via any of the following options (non-exhaustive)

• precision-specific functions such as seconds(nano-timestamp int64), msec(nano-timestamp int64), nsec(nano-timestamp int64)`, etc.
• A since time-precision function such as precision(nano-timestamp int64, precision string/ENUM)
• A generic rounding function that can round any int64.
• Adding more context accessors that know how to Get and Set using the specific associated precision.

@bogdandrutu had the idea to change the time accessors in the ottl contexts to return and accept time.Time values instead of int64. This has the advantage of standardizing how time is returned and set and should solve any potential problems when setting a time with a different precision. It will also open the doors for more complex time transformations such as timezone manipulations

In order to support this change the following items must be addressed:

• [pkg/ottl] OTTL Converter Function that is able to create a new time.Time type from a string. #22007
• [pkg/ottl] Converter Function that is able to create a new time.Duration type from a string. #22015
• [pkg/ottl] Boolean expressions are update to be able to handle comparing time.Time types #22008
• [pkg/ottl] Boolean expressions are update to be able to handle comparing time.Duration types #22713
• [pkg/ottl] Mathematical Expressions are able to handle time.Time and time.Duration types. #22009
• [pkg/ottl] Add Converters for converting time.Time and time.Duration into an number #24686
• [pkg/ottl] Update contexts so that all time fields Getters return time.Time and Setters take time.Time #22010

Describe alternatives you've considered

No response

Additional context

We will need to be careful not to break any usage of set and a timestamp field. At the moment all timestamp Setters expect an int64 that is representative of nanoseconds since epoch time. If we create any functions that change the precision, we need to help users not break their timestamps if they try to use them in set.

Related to #12974
Related to #14142

[TylerHelmuth]

@bogdandrutu had the idea to change the time accessors in the ottl contexts to return and accept time.Time values instead of int64. This has the advantage of standardizing how time is returned and set and should solve any potential problems when setting a time with a different precision. It will also open the doors for more complex time transformations such as timezone manipulations

In order to support this change the following items must be addressed:

• There is an OTTL Factory Function, probably called Time, that is able to create a new time.Time type from a string. Something similar to https://pkg.go.dev/time#Parse can be used.
• OTTL Boolean expressions are update to be able to handle comparing time.Time types
• OTTL Mathematical Expressions are able to handle addition and subtraction for time.Time types.
• OTTL contexts are updated so that all time fields Getters return time.Time and Setters take time.Time. The accessor names should be updated to drop the time precision (_nano).

[github-actions]

This issue has been inactive for 60 days. It will be closed in 60 days if there is no activity. To ping code owners by adding a component label, see Adding Labels via Comments, or if you are unsure of which component this issue relates to, please ping @open-telemetry/collector-contrib-triagers. If this issue is still relevant, please ping the code owners or leave a comment explaining why it is still relevant. Otherwise, please close it.

Pinging code owners:

• processor/transform: @TylerHelmuth @kentquirk @bogdandrutu @evan-bradley
• pkg/ottl: @TylerHelmuth @kentquirk @bogdandrutu @evan-bradley

See Adding Labels via Comments if you do not have permissions to add labels yourself.

[github-actions]

This issue has been inactive for 60 days. It will be closed in 60 days if there is no activity. To ping code owners by adding a component label, see Adding Labels via Comments, or if you are unsure of which component this issue relates to, please ping @open-telemetry/collector-contrib-triagers. If this issue is still relevant, please ping the code owners or leave a comment explaining why it is still relevant. Otherwise, please close it.

Pinging code owners:

• processor/transform: @TylerHelmuth @kentquirk @bogdandrutu @evan-bradley
• pkg/ottl: @TylerHelmuth @kentquirk @bogdandrutu @evan-bradley

See Adding Labels via Comments if you do not have permissions to add labels yourself.