Add More cxjs_*() Functions

[Lightning11wins]

Several of the cxjs_*() functions that I added in #112 turned out more complex than I expected. Note that #112 is higher priority than this PR.

This PR adds the following additional functions:

• cxjs_wordify()
• cxjs_parsedate()
• cxjs_datepart()
• cxjs_datediff()
• cxjs_dateformat()

[greptile-apps]

Greptile Summary

This PR adds five JavaScript helper functions to ht_render.js: cxjs_wordify() (integer-to-English-words), cxjs__parsedate() (internal date parser), cxjs_datepart(), cxjs_datediff(), and cxjs_dateformat(). The internal cxjs__parsedate helper is shared by all three date functions, so a correctness issue there propagates to all callers.

• cxjs__parsedate uses JavaScript's new Date(year, …) constructor directly with the parsed year, which silently maps any year 0–99 to 1900+year; this affects all three date-facing public functions.
• cxjs_wordify has an off-by-one in its comma/space separator logic: chunks of exactly 100 (e.g., "One Hundred Thousand") are treated as a "round" group and receive a space, while 200, 300, … also have no ones/tens but receive a comma, producing inconsistent output for numbers like 100,001 vs 200,001.

Confidence Score: 3/5

Safe to merge for most practical date ranges; the year 0–99 bug will produce wrong output for any date string whose year is two digits or fewer, and the comma inconsistency in wordify produces subtly wrong English for numbers like 100,001.

The shared cxjs__parsedate helper is called by every date function added in this PR. Passing a year in the range 0–99 causes a silent wrong result (e.g., year 50 → 1950) that propagates through cxjs_datepart, cxjs_datediff, and cxjs_dateformat without any error signal. The cxjs_wordify comma-separator issue is a logic inconsistency rather than a crash, but it makes the function output inconsistently formatted depending on whether the hundreds digit is exactly 1.

centrallix-os/sys/js/ht_render.js — specifically cxjs__parsedate (lines 586–594) and the separator condition in cxjs_wordify (line 566).

Important Files Changed

Filename	Overview
centrallix-os/sys/js/ht_render.js	Adds five new cxjs_*() helper functions for date/number formatting; the shared cxjs__parsedate helper mishandles years 0–99 (JavaScript Date constructor quirk), and cxjs_wordify has an inconsistent comma-separator condition for chunk === 100.

Flowchart

%%{init: {'theme': 'neutral'}}%%
flowchart TD
    A[cxjs_wordify] -->|returns string| OUT1[English words]
    B[cxjs_datepart] --> P[cxjs__parsedate]
    C[cxjs_datediff] --> P
    D[cxjs_dateformat] --> P
    P -->|new Date year,month-1,day| E{year 0-99?}
    E -->|yes| WRONG[Wrong: 1900+year]
    E -->|no| OK[Correct Date]
    OK --> B
    OK --> C
    OK --> D

Loading

_{Reviews (1): Last reviewed commit: "Add functions." | Re-trigger Greptile}

[greptile-apps]

Year 0–99 interpreted as 1900+year

JavaScript's Date constructor maps a two-argument-style year (0–99) to 1900+year. Any date string with a year in that range — e.g., "1/1/0050" — will be silently parsed as 1950 instead of 50 CE, causing wrong results from every caller (cxjs_datepart, cxjs_datediff, cxjs_dateformat). Use setFullYear after construction to override this behavior: const d = new Date(0, month-1, day, h, m, s, 0); d.setFullYear(year);

[greptile-apps]

Inconsistent comma separator for chunk === 100

The condition chunk%10 !== 0 || chunk > 100 treats an exact-hundred chunk (e.g., 100) as a "round" group (gets a space) while 200, 300, … (also multiples of 100 with no ones/tens) are considered "complex" and get a comma. This means cxjs_wordify(100001) → "One Hundred Thousand One " (no comma) whereas cxjs_wordify(200001) → "Two Hundred Thousand, One " (with comma), despite both having the same structural complexity. Changing > 100 to >= 100 makes the rule consistent.

Suggested change

	if (chunk > 10 && (chunk%10 !== 0 || chunk > 100) && multiple !== 0)
	if (chunk > 10 && (chunk%10 !== 0 || chunk >= 100) && multiple !== 0)

Note: If this suggestion doesn't match your team's coding style, reply to this and let me know. I'll remember it for next time!

[Lightning11wins]

This isn't high priority right now. I'll come back to it after I clean up exp_functions.c and know what the intended functionality for these functions should be.