fix(gcp_cloud_storage sink): apply timezone to key_prefix strftime#25541
fix(gcp_cloud_storage sink): apply timezone to key_prefix strftime#25541xfocus3 wants to merge 1 commit into
Conversation
The `gcp_cloud_storage` sink built its key partitioner from the raw `key_prefix` template without applying the configured `timezone` offset, so strftime specifiers in `key_prefix` (e.g. `%Y%m%d/`) were always rendered in UTC. The `aws_s3` sink already applies the offset via `Template::with_tz_offset`; this change mirrors that behavior so date-based object partitioning honors the `timezone` (or global `timezone`) setting. Adds a regression test covering positive/negative/none offsets around the UTC day boundary. Closes vectordotdev#25090
There was a problem hiding this comment.
💡 Codex Review
Here are some automated review suggestions for this pull request.
Reviewed commit: e414b8467a
ℹ️ About Codex in GitHub
Codex has been enabled to automatically review pull requests in this repo. Reviews are triggered when you
- Open a pull request for review
- Mark a draft as ready
- Comment "@codex review".
If Codex has suggestions, it will comment; otherwise it will react with 👍.
When you sign up for Codex through ChatGPT, Codex can also answer questions or update the PR, like "@codex address that feedback".
| let offset = self | ||
| .timezone | ||
| .or(cx.globals.timezone) | ||
| .and_then(timezone_to_offset); |
There was a problem hiding this comment.
Preserve DST-aware timezone rules
When timezone is a named zone with daylight saving time, this converts it once with timezone_to_offset, which freezes the offset based on Utc::now() at sink build time before Template formats each event timestamp. In a sink configured with America/Los_Angeles, if Vector starts during PDT (-07) but renders a winter event such as 2026-12-01T07:30:00Z (still Nov 30 in PST -08), the key prefix is formatted using -07 and lands under Dec 1 instead of Nov 30. The template needs the named timezone, or an offset computed from the event timestamp, rather than a build-time fixed offset.
Useful? React with 👍 / 👎.
Summary
Fixes #25090. The
gcp_cloud_storagesink ignored the configuredtimezoneoption when renderingstrftimespecifiers inkey_prefix, so date-based object partitioning (e.g.key_prefix = "%Y%m%d/") always used UTC. Theaws_s3sink already honorstimezoneforkey_prefixviaTemplate::with_tz_offset; this brings the GCS sink in line.Root cause
GcsSinkConfig::key_partitionerbuilt theKeyPartitionerstraight from the rawkey_prefixtemplate:The timezone offset (
timezone→ falling back to the globaltimezone) was computed inRequestSettings::newand applied only to the filename timestamp, never to thekey_prefixtemplate.aws_s3instead doesTemplate::try_from(...)?.with_tz_offset(offset)before constructing its partitioner.Fix
Compute the offset in
build_sinkthe same wayaws_s3does, thread it intokey_partitioner, and apply it withTemplate::with_tz_offset. Behavior with no timezone configured is unchanged (renders in UTC).Testing
cargo test --lib --no-default-features --features sinks-gcp gcp::cloud_storage— 16 passed, 0 failed, including the newgcs_key_prefix_honors_timezone_offsetregression test which asserts a2026-04-01T00:30:00Zevent renders as20260401/under UTC+08:00,20260331/under UTC-08:00, and20260401/with no timezone.cargo clippy --lib --no-default-features --features sinks-gcp -- -D warnings— clean.cargo fmt --check— clean.changelog.d/25090_gcs_key_prefix_timezone.fix.mdvalidated with./scripts/check_changelog_fragments.sh.