Apply suggestion from @ywwg

Co-authored-by: Owen Williams <owen.williams@grafana.com>
Signed-off-by: Bartlomiej Plotka <bwplotka@gmail.com>

Author: bwplotka

proposals/0060-ct-storage.md

@@ -184,7 +184,7 @@ General decisions and principles affecting smaller technical parts:
 
 2. Similarly, we propose to not have special CT storage cases per metric types. TSDB storage is not metric type aware, plus some systems allow optional CTs on gauges (e.g. OpenTelemetry). We propose keeping that storage flexibility.
 
-3. We propose to treat CT as an *optional* data everywhere, simply because it's new and because certain metric type do not need it (gauges). For efficiency and consistency with scrape and Remote Write protocols we treat default value `int64(0)` as a "not provided" sentinel. This has a consequence of inability to provide the CT of an exact 0 value (unlikely needed and if needed clients needs to use 1m after or before.
+3. We propose to treat CT as an *optional* data everywhere, simply because it's new and because certain metric type do not need it (gauges). For efficiency and consistency with scrape and Remote Write protocols we treat default value `int64(0)` as a "not provided" sentinel. This has a consequence of inability to provide the CT of an exact 0 value (unlikely needed and if needed clients needs to use 1m after or before).
 
 4. Given the [CT and ST context](#background-ct-cumulative-vs-st-delta) the CT vs ST meaning blurs. We could rename CT feature now to ST to be consistent with other systems. We propose to stick to "created timestamp" (CT) naming in Prometheus instead of attempting to rename some or all uses to "start timestamp" (ST). The main reason being that CT and ST naming is equally "correct" on storage and given Prometheus is cumulative-first system, we stick to CT. See (and challenge!) the rationales in the [alternative](#rename-ct-to-st).