fix: epoch converter showing wrong UTC and IST times

[Amark19]

The bug

On the epoch timestamp converter, both output fields were wrong for anyone browsing from IST. Epoch 1785828555 rendered as:

Field	Showed	Correct
UTC	2026-08-04 12:59:15	2026-08-04 07:29:15
IST	2026-08-04 18:29:15	2026-08-04 12:59:15

The UTC field was off by +5:30 and the IST field was double-offset.

Root cause

formatDateTime() read the date with local-time getters (getFullYear, getHours, …). Since the browser was in IST:

• epochToUTC() formatted the date in local time and labelled it UTC → printed IST.
• epochToIST() pre-adds IST_OFFSET_MS and then the local getters added another +5:30 → double offset.

istToEpoch() had the same class of bug in reverse — it built the date with the local-time Date(...) constructor before subtracting the IST offset, so it was only correct in a UTC browser. Fixed here too, since it was silently wrong for non-IST visitors.

utcToEpoch() was already correct (it used Date.UTC) and is unchanged.

The fix

Use the UTC APIs — getUTC* in formatDateTime(), Date.UTC(...) in istToEpoch() — so output no longer depends on where the visitor is.

Testing

Property-tested the conversion helpers against an independent oracle (Intl.DateTimeFormat with timeZone, i.e. real tzdata rather than this file's own offset arithmetic).

20,136 assertions × 10 visitor timezones = 201,360 checks, 0 failures.

Coverage per zone:

• 5,000 pseudorandom epochs spanning 1970–2100, each checked for UTC output, IST output, and round-trip back through both utcToEpoch and istToEpoch
• DST transition instants (US, EU, AU, BR) at ±1s and ±1h around the jump — the blast radius of the original local-getter bug
• Boundaries and negatives: 0, ±1, -19800 (IST epoch zero), 86399/86400, 4102444800, 253402300799
• Leap days (2024, 2020, 2100) and year boundaries
• Fractional epochs (1785828555.7)

Zones: Asia/Kolkata, America/Los_Angeles, UTC, Australia/Sydney, Asia/Kathmandu (+5:45), Europe/London, America/St_Johns (−3:30), Pacific/Chatham (+12:45), Asia/Tokyo, America/Sao_Paulo.

Control run — the identical suite against the pre-fix code, to confirm the tests are actually sensitive:

Browser TZ	Pre-fix failures	Post-fix
Asia/Kolkata	15,136 / 20,136	0
America/Los_Angeles	15,136 / 20,136	0
UTC	0	0

The old code passing cleanly under UTC and failing everywhere else confirms the root cause: it was accidentally correct in exactly one timezone.

Not covered

Verified in Node against the extracted conversion helpers — not in a real browser. The DOM wiring (click handler, date/time pickers, parseDateTime input formats, the "current time" button) is unexercised and worth a manual click-through. Those paths are unchanged by this PR.

Notes

• No collectstatic needed: this repo has no static/ source tree, so staticfiles/ is the served copy.
• scripts/uglify-minify.sh runs terser in place and isn't wired into CI, so it doesn't affect this change.
• Static JS is usually cached — worth a cache-bust after deploy.
• CI is red for unrelated reasons: flake8 fails on views_converters.py (W292) and views_textanalyzer.py (W391), both pre-existing on master at a1012bd. This PR changes one JS file and no Python.