Repository navigation
Accept a UTC or GMT zone word of 24 hours or more in timestamp date strings - #329
luisleo526 wants to merge 2 commits into
Conversation
timestamp("01 Feb 2024 00:00 UTC+24"), the same string with GMT-24 and with
UTC+25 are accepted by TradingView, which reads the zone word as plain
arithmetic on the wall-clock fields. The translator stops on them with an
internal ValueError instead of emitting the constant.
The new file pins the three values TradingView's exported trade lists decode
to (1706659200000, 1706832000000 and 1706655600000 ms), the same string as an
input.time default, the build of the emitted C++ for the three strings, and
six neighbouring forms that already translate (no zone, a bare UTC word,
UTC+2, GMT-5:30, UTC+23, UTC-23) so that the repair can be seen to move none
of them.
Co-Authored-By: Claude Sonnet 5.5 <[email protected]>
…trings
timestamp("01 Feb 2024 00:00 UTC+24") raised an internal ValueError because
the zone word was turned into a datetime.timezone, which refuses an offset of
24 hours or more. TradingView treats the word as plain arithmetic on the date
fields: its exported trade lists for UTC+24, GMT-24 and UTC+25 decode to the
fields read as UTC minus the signed offset. The offset is now kept as a
timedelta and subtracted from the UTC reading of the fields.
The value for an offset under 24 hours, a bare UTC word, a string without a
zone and a string that carries its own numeric offset is unchanged.
Co-Authored-By: Claude Sonnet 5.5 <[email protected]>
![graphify-labs[bot]](https://avatars.githubusercontent.com/in/4356270?s=60&v=4){kind=small}
There was a problem hiding this comment.
Graphify reviewed this change.
Worth a look — the grounded gate found no coupling regressions or blocking issues, but 1 advisory finding(s) below merit a look before merge.
Not checked: tests were not run; formal verification proved 0 of 1 changed function(s) (1 sampled, not proven).
Formal verification. PR-changed functions: 1/1 verified (0 proven, 1 may-equivalent, 0 distinguished) · 0 not verified.
Graphify review — findings
Fixes timestamp("...") for UTC/GMT zone words of 24 hours or more (UTC+24, GMT-24, UTC+25), which used to stop with an internal ValueError and now emit the constant. _parse_pine_datestring_ms reads the date fields as UTC and subtracts the signed offset as plain arithmetic, matching TradingView, instead of building a datetime.timezone. The sign of the minutes part is still derived from the hours value, so offsets with a zero hours part like -0:30 are the risky spot. Adds tests that pin the three TradingView constants, the neighbouring sub-24h forms, an input.time default, and a C++ build check, plus a changelog entry.
Worth a look
- Negative zero-hour minute offsets are treated as positive —
pineforge_codegen/codegen/visit_call.py:277· Escalate · medium- NOT verified (no proof, no reproducing execution) — needs human review
Analysis details — impact, health, verification
Impact & health
Graphify review
Impact — 210 functions depend on the 204 functions this change touches.
Health — grade A; no new coupling hotspots.
Verification — 210 functions in the blast radius were not formally verified this run (proofs are advisory here).
Gate & verification
graphify gate
PASS — objectively clean (no health regressions, tests not run — proofs not run this pass (advisory)). Grounded, not self-assessed.
Advisory (not blocking):
- verification_scope: 210 function(s) in the blast radius were not formally verified this run
Cross-repo impact
Cross-repo impact
No cross-repo impact detected among the indexed peer repo(s).
1 peer repo(s) in this group are not yet indexed — cross-repo impact may be incomplete.
Cross-repo linkage is derived (SCIP-moniker matches are sound; name/contract matches are heuristic) and ADVISORY — it never affects this check's conclusion.
Formal verification
No difference found (not proven): No behavior difference found in \_parse\_pine\_datestring\_ms (not a proof).
The verifier ran both versions of \_parse\_pine\_datestring\_ms on many inputs and saw identical behavior every time. Strong evidence the change is safe, but evidence, not a proof.
Guarantee: Empirical: differential testing (both versions run on many generated inputs). A divergence on an untested input remains possible, so this is 'no counterexample found', not 'proven equivalent'.
Note: An input the sampler did not try could still differ.
What
timestamp("01 Feb 2024 00:00 UTC+24"), the same string withGMT-24and withUTC+25stopped the translator with an internalValueError(offset must be a timedelta strictly between -timedelta(hours=24) and timedelta(hours=24)) instead of emitting a constant. TradingView accepts these strings. They now translate.Why
The
UTC/GMTzone word of a date string was turned into adatetime.timezone, and Python refuses atimezoneof 24 hours or more. TradingView does not limit the word: its exported trade lists for scripts built on the three strings decode to the date fields read as UTC minus the signed offset, whatever its size.01 Feb 2024 00:00 UTC+2401 Feb 2024 00:00 GMT-2401 Feb 2024 00:00 UTC+25(
01 Feb 2024 00:00read as UTC is 1706745600000.)How
_parse_pine_datestring_mskeeps the zone word as atimedeltaand subtracts it from the UTC reading of the date fields. A string without a zone, a bareUTCword, a zone under 24 hours and a string that carries its own numeric offset follow the same path as before. Two files change (pineforge_codegen/codegen/visit_call.py,CHANGELOG.md) plus the new test file.Verification
tests/test_timestamp_zone_offsets.py(13 tests, committed before the fix): on the tree without the fix 7 fail, all with theValueErrorabove (the three values, the same string as aninput.timedefault, and the three builds of the emitted C++), and the 6 neighbouring forms pass; with the fix 13 pass, none skipped. The expected values are the TradingView values in the table, not computed by the fixed function.timestamp(...)call: 1300 passed, none skipped, with and without the fix.9ee1cc7d, BTCUSDT 1h: forUTC+24andGMT-24every entry matches (time and quantity). ForUTC+25the date value matches (the sign entry and four of the five digit chunks); the fifth entry differs becauseint(math.floor(x))of a 1.7e12 double reads as the integernasentinel in the engine, an effect that is the same, at the same entry with the same quantity, on 16 other probes that translate without this change.🤖 Generated with Claude Code