fix: time2str stores wrong epoch when timezone is specified#141
Draft
Koan-Bot wants to merge 1 commit into
Draft
fix: time2str stores wrong epoch when timezone is specified#141Koan-Bot wants to merge 1 commit into
Koan-Bot wants to merge 1 commit into
Conversation
When time2str is called with a timezone, $time is modified by tz_offset()
before gmtime(), but then the modified value was stored in $me->[9].
Format codes that read $me->[9] (format_G for GPS week, format_z for
numeric offset DST detection) got the wrong timestamp.
strftime already stored $epoch (real epoch) correctly — this aligns
time2str with the same behavior.
The bug manifests at GPS week boundaries: time2str("%G", $t, "EST")
returned week N-1 instead of N when the timezone offset pushed the
adjusted time across the 604800-second boundary.
Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
What
time2strstored the timezone-adjusted epoch in$me->[9]instead of the real epoch, causing format codes that read$me->[9]to compute wrong values.Why
format_G(GPS week number) andformat_z(numeric timezone offset) both read$me->[9]expecting the real Unix epoch. Whentime2stris called with a timezone,$timeis modified bytz_offset()beforegmtime(), but the modified value was stored in$me->[9]. This causes GPS week numbers to be off by 1 at week boundaries with non-UTC timezones, and potentially wrong DST detection informat_z.strftimealready stored$epoch(real epoch) correctly — this was atime2str-only bug.How
One-line fix:
$me->[9] = $epoch;instead of$me->[9] = $time;(line 95 of Generic.pm).$epochis set to the original time on line 79, before$timeis modified.Testing
New
t/time2str-tz-epoch.twith 8 tests:%s(format_s) still returns real epoch (uses$epochdirectly, unaffected)Full test suite passes (all 38 test files).
🤖 Generated with Claude Code
Quality Report
Changes: 2 files changed, 44 insertions(+), 1 deletion(-)
Code scan: clean
Tests: skipped
Branch hygiene: clean
Generated by Kōan post-mission quality pipeline