Category
Timestamp Conversion Thresholds (seconds ↔ milliseconds detection)
Locations
core/src/exchanges/probable/normalizer.ts:109 — raw.time < 1e12 ? raw.time * 1000 : raw.time (Trade)
core/src/exchanges/probable/normalizer.ts:136 — raw.time > 1e12 ? raw.time : raw.time * 1000 (UserTrade)
core/src/exchanges/probable/websocket.ts:103 — if (timestamp < 10000000000)
core/src/exchanges/kalshi/websocket.ts:406 — if (timestamp < 10000000000)
core/src/exchanges/kalshi/websocket.ts:412 — if (timestamp < 10000000000)
core/src/exchanges/polymarket/fetcher.ts:17 — d < 1e12 ? d * 1000 : d
core/src/exchanges/opinion/utils.ts:79 — ts < 10_000_000_000 ? ts * 1000 : ts
sdks/typescript/pmxt/server-manager.ts:304 — info.timestamp > 1e12 ? info.timestamp / 1000 : info.timestamp
sdks/python/pmxt/server_manager.py:207 — timestamp / 1000.0 if timestamp > 1e12 else float(timestamp)
Inconsistencies
Three different notations for the same value across the codebase:
| Notation |
Files |
1e12 |
probable/normalizer.ts, polymarket/fetcher.ts, server-manager.ts, server_manager.py |
10000000000 |
kalshi/websocket.ts, probable/websocket.ts |
10_000_000_000 |
opinion/utils.ts |
Potential logic bug in probable/normalizer.ts: The Trade normalizer (line 109) uses < 1e12 while the UserTrade normalizer (line 136) uses > 1e12 as the condition for the same semantic check. Although both branches produce the same result, the inverted condition is error-prone — a future edit to one method risks introducing an actual divergence.
Risk
A wrong threshold or copy-paste of the inverted condition produces timestamps off by ×1000 (year 33658 vs. 2001), silently corrupting order books, trade history, and any downstream time-series logic. The three-way notation inconsistency makes a search-and-replace correction easy to miss.
Suggested Fix
Extract a single shared utility (already partially present in opinion/utils.ts):
// core/src/utils/timestamp.ts
export const MILLIS_THRESHOLD = 1e12; // ~year 2001 in ms; values below are assumed seconds
export function toMillis(ts: number): number {
return ts < MILLIS_THRESHOLD ? ts * 1000 : ts;
}
Replace all 9 call-sites with toMillis(). The Python SDK should mirror with a shared helper.
Found by automated magic numbers audit
Category
Timestamp Conversion Thresholds (seconds ↔ milliseconds detection)
Locations
core/src/exchanges/probable/normalizer.ts:109—raw.time < 1e12 ? raw.time * 1000 : raw.time(Trade)core/src/exchanges/probable/normalizer.ts:136—raw.time > 1e12 ? raw.time : raw.time * 1000(UserTrade)core/src/exchanges/probable/websocket.ts:103—if (timestamp < 10000000000)core/src/exchanges/kalshi/websocket.ts:406—if (timestamp < 10000000000)core/src/exchanges/kalshi/websocket.ts:412—if (timestamp < 10000000000)core/src/exchanges/polymarket/fetcher.ts:17—d < 1e12 ? d * 1000 : dcore/src/exchanges/opinion/utils.ts:79—ts < 10_000_000_000 ? ts * 1000 : tssdks/typescript/pmxt/server-manager.ts:304—info.timestamp > 1e12 ? info.timestamp / 1000 : info.timestampsdks/python/pmxt/server_manager.py:207—timestamp / 1000.0 if timestamp > 1e12 else float(timestamp)Inconsistencies
Three different notations for the same value across the codebase:
1e121000000000010_000_000_000Potential logic bug in
probable/normalizer.ts: TheTradenormalizer (line 109) uses< 1e12while theUserTradenormalizer (line 136) uses> 1e12as the condition for the same semantic check. Although both branches produce the same result, the inverted condition is error-prone — a future edit to one method risks introducing an actual divergence.Risk
A wrong threshold or copy-paste of the inverted condition produces timestamps off by ×1000 (year 33658 vs. 2001), silently corrupting order books, trade history, and any downstream time-series logic. The three-way notation inconsistency makes a search-and-replace correction easy to miss.
Suggested Fix
Extract a single shared utility (already partially present in
opinion/utils.ts):Replace all 9 call-sites with
toMillis(). The Python SDK should mirror with a shared helper.Found by automated magic numbers audit