Current Time
Check one browser-clock instant in local and UTC forms, capture stable ISO 8601 and Unix values, and spot a nearby date boundary.| Metric | Value | Copy |
|---|---|---|
| {{ row.label }} | {{ row.value }}{{ row.value }} |
| Priority | Check | Guidance | Copy |
|---|---|---|---|
| {{ row.priority }} | {{ row.title }} | {{ row.message }} |
One instant can carry many correct labels. At the same moment, a device may show Tuesday evening, Coordinated Universal Time (UTC) may already be Wednesday, and a Unix timestamp may show only a count of seconds. Confusion starts when a time is copied without the basis that gives it meaning.
Local time is useful for people working in one place. UTC is the steadier reference for logs, distributed systems, audits, and handoffs across regions. An ISO 8601 instant ending in Z makes UTC explicit, while a local clock value should travel with its UTC offset and, when possible, its time-zone identifier.
A time zone is more than a fixed offset. Its civil-time rules may change seasonally or historically, so UTC+01:00 does not identify the same rule set as a named zone. Near midnight, local and UTC dates can differ even though both refer to the same instant. Relative phrases such as “today” and “tomorrow” then become ambiguous across regions.
Precision also needs a purpose. Minutes are calm and readable for a wall display; seconds help coordinate operations; milliseconds can distinguish closely spaced events. Extra digits do not guarantee accuracy. A browser reads the device clock, and a badly synchronized device can produce a precise-looking but incorrect timestamp.
For evidence that must remain stable, capture one instant before copying values. Otherwise a table, chart, and exported record can be read at slightly different moments, especially near a date boundary.
How to Use This Tool:
Choose how the same browser-clock instant should be presented, then freeze it when the values need to stay together.
- Select Device local time for the device's civil clock or UTC reference time for a region-neutral display.
- Choose minute, second, or millisecond Precision, then keep the device-locale clock style or force a 24-hour or 12-hour display.
- Set Guidance focus to match a cross-time-zone handoff, readable display, or audit record. This changes the advice, not the timestamp.
- Use the live clock for observation. Capture the moment before copying or exporting evidence so every representation refers to one timestamp; resume live mode when finished.
- Check Boundary guidance when the local and UTC dates differ or either midnight is close. Share ISO 8601 or Unix time instead of a relative date word in that case.
Interpreting Results:
Displayed time follows the chosen local or UTC basis. ISO 8601, UTC reference string, and both Unix timestamps describe the same instant independently of that display choice.
Calendar split means the device-local date and UTC date differ. Rollover soon means either local or UTC midnight is within two hours, provided the dates are not already split. Include the full date, basis, and offset when sharing a value under either condition.
The seasonal-offset message is only a clue derived from the device zone's January and July offsets. More importantly, none of the results proves that the device clock agrees with an official time source. Compare against a trusted time service when clock accuracy matters.
Technical Details:
The browser supplies one integer timestamp in milliseconds since the Unix epoch. Local and UTC labels, calendar dates, week values, day progress, and midnight guidance are all derived from that same instant, which prevents the representations from drifting apart after capture.
Formula Core
Unix seconds discard the sub-second remainder; Unix milliseconds preserve the browser time value.
Day progress uses the actual interval between the selected day's midnight and its next midnight. A local day can therefore be shorter or longer than 24 hours when the device zone changes offset.
Elapsed hours, remaining hours, and progress percent are rounded to four decimal places. The visible clock follows the chosen precision, but the canonical timestamp remains in whole milliseconds.
Mechanism Core
| Representation | Basis | Important property |
|---|---|---|
| ISO 8601 | UTC | Always includes milliseconds and the Z UTC designator. |
| Unix seconds | Epoch | Whole seconds obtained by flooring milliseconds divided by 1,000. |
| Unix milliseconds | Epoch | The unrounded browser timestamp. |
| Local date and time | Device zone and current UTC offset | Uses the browser's current zone identifier and civil-time rules. |
| UTC date and time | UTC | Unaffected by the selected local display basis. |
| ISO week | Selected local or UTC calendar date | Weeks begin Monday and week 1 follows the ISO week-year rule. |
The boundary rule first checks whether local and UTC calendar dates differ. If they do, the status is Calendar split. Otherwise, a remaining interval of 7,200,000 milliseconds or less to either midnight produces Rollover soon; all other instants are Same calendar day.
The accepted timestamp range runs from the Unix epoch through the start of 2100. UTC offsets must be whole minutes from −840 through +840, matching the supported −14 to +14 hour range. Day-of-year output is 1 to 366 and ISO week output is 1 to 53.
Accuracy and Privacy Notes:
Time values are calculated in the browser from the device clock and time-zone data; no time lookup is sent to a checker service. That keeps the timestamp local, but it also means the result inherits any device-clock, operating-system, or time-zone-data error.
- A capture locks the displayed instant. It does not resynchronize or correct the clock.
- The January-versus-July comparison is a seasonal-offset clue, not a complete history of daylight-saving rules.
- Unix and ECMAScript time treat every day as 86,400 seconds and do not represent leap seconds as separate time values.
- Copying a local time without its date, offset, and zone can still make an accurate value ambiguous.
Worked Examples:
New Year across a five-hour offset
A captured instant of 2026-01-01T00:30:00.000Z is Unix second 1,767,227,400. On a device at UTC−05:00 it is still 19:30 on 2025-12-31. The local and UTC labels are both correct, but the result is Calendar split; sharing “today at 19:30” would lose the instant, while the ISO value remains unambiguous.
References:
- ECMAScript Date Objects, Ecma International.
- Seconds Since the Epoch, The Open Group Base Specifications Issue 8, 2024.
- Time Zone Database, Internet Assigned Numbers Authority.
- NIST Internet Time Service, National Institute of Standards and Technology.