Repository navigation
timestamp(dateString) refuses a full month name such as '01 February 2024 00:00' #293
Description
Summary
timestamp() with a date string that spells the month in full is refused at translation. The same date with the abbreviated month and an offset, or with numeric arguments, translates and runs.
Versions
pineforge-codegen 1.9.1, and main at c1cc532 (after #290) run from source: same refusal. The control was built with pineforge-engine v1.9.1 (fc0a2df), Apple clang 17.0.0, macOS 15.8 arm64, and run on BTCUSDT 1h bars from 2024-01-01 to 2024-03-01. The refusal comes from the front end, so it should not depend on the platform.
Reproduction
//@version=6
strategy('repro')
start = timestamp('01 February 2024 00:00')
if time >= start and bar_index % 20 == 0
strategy.entry('Long', strategy.long)
if bar_index % 20 == 10
strategy.close('Long')
CODEGEN 3:18 timestamp(dateString): could not parse '01 February 2024 00:00'.
Control: start = timestamp('UTC', 2024, 2, 1, 0, 0) translates and runs, 34 trades, the first on bar 761.
Expected
The script translates and runs as the control. Checked on TradingView (BINANCE:BTCUSDT 1h): the script compiles, start is 1706745600000 (2024-02-01 00:00 UTC) as with the control, and both give the same list of trades (34 trades over the same 1,441 bars, the first on bar 761). The timestamp() reference only shows abbreviated months in its examples.
Workaround
Use the abbreviated month ('01 Feb 2024 00:00 +0000' translates and gives the same 34 trades) or the numeric form.
Activity
luisleo526 commentedon Nov 1, 2026
Thank you for the detailed report. We are checking each case against TradingView's behaviour and our source, and will post a result for each case in this issue by the end of 2026-11-03 (UTC). If a case needs longer, we will say so here with the reason.
luisleo526 commentedon Nov 3, 2026
Thank you for the report and for checking it on TradingView. This is the result on the released pineforge-codegen 1.10.0. The fix is planned for the next release (1.10.1), as the 1.10.0 release notes list for this issue.
timestamp('01 February 2024 00:00')(full month name)timestamp(dateString): could not parse '01 February 2024 00:00'.You checked on TradingView that the same date compiles there and gives 1706745600000 (2024-02-01 00:00 UTC), as your numeric control does'01 Feb 2024 00:00 +0000')timestamp('UTC', 2024, 2, 1, 0, 0)The full-month-name case is a defect: the date-string parser accepts ISO dates and abbreviated month names, and has no full-month-name formats. The fix is planned for the next release (1.10.1); the issue stays open until it is released. The workaround you gave (the abbreviated month, or the numeric form) keeps working.
luisleo526 commentedon Nov 6, 2026
The fix, merged in #327 (commit 08261a2), is on main and not yet released; it ships in the next release and the issue closes then. The reported full-month timestamp form now emits the TradingView value 1706745600000, matching the value in the report. The check covered the timestamp translation; it did not run the report's separate trade-count comparison.
luisleo526 commentedon Nov 8, 2026
Update: the full-month timestamp fix is on main; the next release is 1.11.0.
The translation was checked on 2026-11-06 on main after #327 (
08261a24) landed, as reported in our earlier comment. It was not re-run today; that comment identifies the fix commit but does not record the exact tested main commit.timestamp('01 February 2024 00:00')(full month name)08261a24)'01 Feb 2024 00:00 +0000')timestamp('UTC', 2024, 2, 1, 0, 0)The check covered timestamp translation. The report's separate trade-count comparison was not run.
This is fixed on main and ships in 1.11.0, whose publish target is 2026-11-10. This issue will be closed when that release is published.
Clarify unreleased fixes and numeric helper documentation (#353)
luisleo526 commentedon Nov 9, 2026
Fixed in v1.11.0. The fix is part of the v1.11.0 release; its test modules pass on v1.11.0 together with the current engine.