Seconds, milliseconds, and Asia/Kolkata
I convert timestamps here when a log line, a JWT exp, and a SQL timestamptz disagree by a factor of 1000 or by five and a half hours. The arithmetic is JavaScript Date. That means Unix time without leap seconds, browser TZ data for named zones, and millisecond precision internally. It is not a TZ database maintainer, not an astronomy clock, and not a cron scheduler — use the cron visualizer for five-field schedules.
India Standard Time is UTC+5:30 all year. There is no DST to forget in Kolkata. The bug I still hit is treating IST as UTC+5 and landing thirty minutes off, or sending UTC ISO strings to a server that logs “local” without naming the zone. This page can show UTC, your browser’s local zone, New York, or London. If your laptop is already set to Kolkata, “Local Time” is IST. If you are on a US VPS, “Local Time” is not IST — pick UTC and add 5:30 yourself, or you will debug the same outage twice.
Worked example: ten digits versus thirteen
1700000000 as Unix seconds is 2023-11-14 22:13:20 UTC, which is 2023-11-15 03:43:20 IST. Same digits as Unix milliseconds — input format “milliseconds” — is 1970-01-20 11:33:20 UTC. That is how jobs get scheduled in 1970. Thirteen digits 1700000000000 is the millisecond form of the same November 2023 instant. A JWT exp of 1700000000 is seconds. A JS Date.now() is milliseconds. Mixing them is the classic “token expires in the year 56,000” or “token expired in 1970” ticket.
Worked example: 1725000000 and the +5:30 offset
Enter 1725000000 as seconds, timezone UTC: 2024-08-30 06:40:00 UTC. IST is 12:10 the same calendar day. People who add five hours get 11:40 and then argue with a bank SMS that printed 12:10. ISO-8601 of that instant is 2024-08-30T06:40:00.000Z. If you paste 2024-08-30T12:10:00 without a Z or offset, new Date treats it as local. On a Kolkata laptop that happens to be correct; on GitHub Actions in UTC it is five and a half hours wrong. Always include Z or +05:30.
Worked example: DST where India has none
Switch the zone to America/New_York and convert 2024-03-10T07:00:00.000Z. US DST springs forward that morning; local clocks skip 02:00–03:00. A “daily 2:30am” job in New York may not exist that day. Europe/London has its own spring-forward. Asia/Kolkata will not skip. If your cron runs on an IST container but you converted the fire time with New York selected, you have a fiction. Relative strings like “3 hours ago” use the browser’s now minus the instant — useful for logs, useless as a legal timestamp.
Limits of JS Date
Leap seconds are smeared or ignored; do not build a stopwatch for astronomy. Pre-1970 (negative Unix) works until the Date implementation gets tired — fine for 1950-ish, not for 1 BCE. Human-readable parse of 01/02/2024 is locale-hostile: US vs India day/month. Prefer ISO. RFC 2822 output is UTC via toUTCString() even if you selected IST for the human line — read the label. Invalid input becomes “Invalid date,” not a guess.
Questions
Is IST UTC+5 or UTC+5:30?
UTC+5:30, all year. Adding five hours is a thirty-minute bug that survives every code review that “looked fine.”
How do I tell seconds from milliseconds?
Near “now,” seconds are ten digits (1.7e9). Milliseconds are thirteen (1.7e12). JavaScript Date.now() is milliseconds; JWT exp is seconds.
Why did an ISO string without Z shift by hours on CI?
new Date('2024-08-30T12:10:00') is local time. GitHub Actions is usually UTC. Put Z or +05:30 on the string.
Does this handle leap seconds?
Unix time as used by JS Date effectively ignores them. Do not build astronomy here.
Will New York DST change my IST conversion?
Only if you selected America/New_York. Kolkata has no DST. The dropdown is the zone of the human-readable line, not a second clock.
Can I convert a cron expression here?
No. This is an instant. Recurring schedules belong in the cron visualizer, and that page is Vixie five-field, not Quartz.