Repository navigation
fix(search): stop emitting 1970-01-01 when the search timestamp is a string or zero - #158
Merged
Merged
Conversation
…string or zero news_search / topic_search read `publish_at_timestamp` / `created_at_timestamp` with `v.as_i64().unwrap_or(0)`. The upstream serializes these int64 values as JSON strings (to avoid JS precision loss), so `as_i64()` returns None → 0 → `1970-01-01T00:00:00Z`; a genuine numeric 0 lands there too. Every affected item rendered the epoch. Parse the timestamp robustly (number, float, or string) via a new `as_unix_ts` helper, and omit `time` entirely for a missing/zero/unparseable value instead of emitting a misleading epoch. Regression tests cover string, numeric, and missing/zero/unparseable inputs for both the news and topic transforms.
hogan-yuan
added a commit
that referenced
this pull request
Sep 21, 2026
Minor release from 0.11.2. Includes a breaking change: - feat(symbol)!: send symbols instead of counter_ids, add multi-leg orders (#128) - fix(tools): strip non-standard schema formats (uint/int64/…) (#156) - fix(search): stop emitting 1970-01-01 when the search timestamp is a string or zero (#158) Bumps Cargo.toml, Cargo.lock, and server.json (version + image identifier).
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.
Problem
news_searchandtopic_searchrender"time": "1970-01-01T00:00:00Z"for every item.Root cause
The transforms read
publish_at_timestamp/created_at_timestampwithv.as_i64().unwrap_or(0). The upstream serializes theseint64values as JSON strings (to avoid JS precision loss), soas_i64()returnsNone→0→ epoch. A genuine numeric0lands there too. Either way every affected item shows1970-01-01T00:00:00Z.Fix
as_unix_tshelper parses the timestamp robustly — JSON number, float, or string — and returnsNonefor a missing / non-positive / unparseable value.news/topictransforms use it and omittimewhen there's no valid timestamp, rather than emitting a misleading epoch.Tests
Regression tests for both the news and topic transforms cover:
0/"0"/""/ non-numeric /null→timeomitted.cargo test(316 passed),clippy --all-features --all-targets, and+nightly fmtall clean. Independent of the mainland/.cnchange.