feat: Add time-window conversion via min/max TSDB offsets (day-rounded)

[TaranpreetSingh]

Introduce min/max TimeDate to support for conversion planning using convert.min-time and convert.max-time.

This change enables day-rounded time window selection for conversion via min/max time range. It improves operational control by focusing conversions on a targeted period, reducing unnecessary downloads, compute, and storage for out-of-window data. It supports backfill and selective reprocessing scenarios while preserving default behavior when duration are unset. Duration are interpreted as explicit date and rounded to day boundaries (min to 00:00:00 UTC; max to next day start, exclusive), ensuring consistent, predictable daily block generation.

Key changes

• convert: use Planner.WithTimeWindow(min/max) in advanceConversion; existing per-day conversion loop unchanged.
• TSDB discoverer: expose TimeOffsets() and option setters (TSDBMinTimeOffset/TSDBMaxTimeOffset) to pass CLI flags through.
• Flags help text: clarify that min-time rounds to 00:00:00 UTC; max-time rounds to next day start (exclusive)
  Test result
  with flag used

Without flag

[MichaHoffmann]

they are already on conversion opts, we dont need to pass explicitely.

[TaranpreetSingh]

fixed, by removing them for the func parameter and calling them directly in plan

[MichaHoffmann]

Generally looks good to me, but can you address the nit above and maybe also clean up some of the comments and address the commented test issue?

[TaranpreetSingh]

Generally looks good to me, but can you address the nit above and maybe also clean up some of the comments and address the commented test issue?

When we added the time based sharding , it was not clear how should be passed the real time time range / set the time range for the test block in real time, as the plan use the time.now() cal for the time based sharding. This is been fixed now

[GiedriusS]

Why not just specify everything in days if everything is already rounded to a day? I'm trying to wrap my head around the problem this solves. Is the goal to run multiple converters for a different subset of inputs by day?

[TaranpreetSingh]

Why not just specify everything in days if everything is already rounded to a day? I'm trying to wrap my head around the problem this solves. Is the goal to run multiple converters for a different subset of inputs by day?

Yes, as it can help in multiple ways, like in case of backfill.
On using the days instead of hours, that's a good point, we added this in format of hours to be align with the format of other config like grace period etc.

[GiedriusS]

Same constant 2006-01-02 could be reused. Also, could we move validation one layer up - the caller of this function could check if the inputs are correct and just pass time.Time, no? If a non-empty string is passed then I would expect it to be checked and error out if it doesn't follow the format that is expected.