Stopwatch & lap/split time recording (CSV output) | ZeroTools

The basic operation system of this stopwatch tool consists of direct state control via a group of buttons placed in the center of the screen.

When a user accesses the page and loads the tool, the initial screen displays a digital timer reading 00:00.000 and a primary action button labeled "Start".

Clicking or tapping this Start button switches the internal state variable to running. In conjunction with this, the button's label dynamically changes from Start to Pause, and the system's timekeeping process begins.

While the timekeeping process is ongoing, the large digital numeric display at the top of the screen is continuously updated down to the millisecond, allowing the user to visually check the elapsed time in real time.

If the Pause button is pressed during measurement, the last rendered time state is captured and held in the internal memory area, and the timer's screen update process stops immediately.

It does not precisely remeasure the exact moment of the button press. Simultaneously, the action button's display returns to Start.

When the Start button is pressed again from the paused state, the measurement resumes directly from the previous elapsed time held in the memory area, allowing for the time to be accumulated in multiple segments.

Additionally, pressing the Reset button located to the left of the Start and Pause buttons initializes the elapsed time on the screen to zero, regardless of whether the system is currently running or paused.

When this reset operation is executed, all recorded lap time and split time history data arrays, as well as saved data, are completely cleared without any confirmation prompt, and there is no undo function to restore the data.

The history table and statistical graph displays on the screen are also erased at the same time. Therefore, when performing a reset operation while holding important timekeeping data, users must take precautions such as exporting the data as a CSV file beforehand.

These on-screen UI operations are processed by event listeners within the component.

The stopwatch's elapsed time display formats as MM:SS.mmm if it is under 1 hour, and switches to HH:MM:SS.mmm only after 1 hour has passed, starting from an initial state of 00:00.000.

The internal measurement process uses performance.now(), a monotonic clock based on timeOrigin, and the screen update timing relies on requestAnimationFrame.

The displayed numbers are output to the screen truncated to three digits for milliseconds.

However, this three-digit millisecond display is merely a UI specification outputting internally calculated numbers as a format string; it does not guarantee a 1-millisecond timekeeping or rendering precision for the system as a whole.

Depending on environmental factors such as the browser's processing load, the hardware performance of the executing device, and the display's refresh rate, the timing of the screen render updates can fluctuate.

Therefore, the last digit on the screen does not tick evenly from 0 to 9 one millisecond at a time, and under some conditions, the screen updates discontinuously with skipping values.

While the internal difference calculation itself is based on a high-precision timer provided by the OS, it is important to note that the update frequency reflected in the final UI screen relies entirely on the browser's rendering cycle.

As a function to record the time of specific sections or checkpoints while measuring, this tool implements a recording mechanism using two different time concepts: lap time and split time.

When the system's timekeeping is running, pressing the Lap button with the flag icon immediately adds the time at that moment, based on the last rendered time state, as a new element to the array data structure in memory.

The split time recorded and displayed here refers to the total cumulative elapsed time from the very first starting point of the measurement to the point when the lap button is pressed.

This is a comprehensive time indicator equivalent to the total time from start to the current point. On the other hand, lap time refers to the pure segment time elapsed from the point when the lap button was previously pressed, or the starting point if it is the first lap, to the point when the current lap button is pressed.

In the internal processing logic, the split time is first calculated based on the current time when the lap button is pressed, and the dynamically generated lap time for that specific segment is calculated by subtracting the previously recorded split time held in memory.

The recorded lap information data is immediately displayed as rows in the Lap history table component located on the right or bottom of the screen.

This table aligns three items: the lap number indicating the recording order, the lap time which is the segment time, and the split time which is the total elapsed time.

The data is rendered in reverse array order so that the latest lap record always appears at the top of the table. While there is no hard-coded software limit to the number of laps you can record, it is bound by the memory limits of your environment.

The times in the table are also displayed as MM:SS.mmm for under 1 hour, and HH:MM:SS.mmm for 1 hour or more. Note that the lap button function is only active while the timer is running; in the paused state or initial state before measurement begins, the button event itself is disabled, so pressing it will not record new lap data and will be ignored.

Every time a new lap data is added, the recorded lap time data array is immediately parsed in the browser's memory, and the results are fed back on the screen.

In the Lap statistics area, a process automatically runs to scan all recorded lap time values and calculate three statistical indicators: the fastest lap representing the shortest relative time, the slowest lap for the longest relative time, and the average lap.

In this display area, the fastest lap value is visually highlighted in emerald green text, and the slowest lap value in rose red text.

Furthermore, this highlighting is also applied inside the lap history table. However, if there is only one recorded lap, there is no subject for comparison, so this color-coding process does not trigger.

A feature is also provided to automatically draw a line graph using SVG elements to visually understand the lap time trends. This graph display function is only rendered on the screen once two or more lap data points are recorded.

The graph area places the lap number on the horizontal axis and the lap time length on the vertical axis. The vertical scale is not fixed; ratios are calculated based on the slowest value and the fastest value, dynamically plotting each lap's data point as a relative height.

If all lap times are equal, they are rendered at a 50% height. The data points are connected by linear SVG path elements. Circular nodes are placed on each plotted data point, with the fastest lap node painted green, the slowest lap node painted red, and all other standard lap nodes filled with the main color.

This tool implements an export function to output lap data measured and recorded in the browser as an external file, and a local storage saving function to temporarily retain and restore the measurement state in case the tab is accidentally closed.

Regarding the CSV export function, pressing the Save as CSV button converts all lap data currently held in memory into a string. The CSV includes headers for Lap number, lap time, and split time, using formatted time strings.

It uses a data URI with CRLF line breaks and UTF-8 encoding without a BOM, outputting the data sorted in chronological order with the oldest lap first.

This data conversion and file creation process is executed dynamically in the browser, triggering a click event from the program.

Therefore, there is no network communication involved. The generated file is assigned a filename, and the save location depends on your browser's download settings rather than guaranteeing a specific folder.

Next, regarding the state saving and restoring function, this tool uses the browser's built-in localStorage to save the current elapsed time and lap history array data in JSON format under the zerotools_stopwatch key, which is shared across language pages of the same origin.

However, the timing for triggering this storage write process is limited to only two actions: when the Pause button is pressed, and when the Lap button is pressed.

The real-time elapsed time while the timer is running is not continuously saved to storage, and saving can fail due to storage limits.

If a user reloads the page, the tool always reconstructs the timer numbers and lap history as a stopped snapshot. Therefore, if you leave the timer running and close the tab, there is no continuous measurement while closed, and the tool will only restore the state exactly as it was at the moment of your last pause or lap action.

When using this stopwatch tool for long-duration measurements or in environments where background operation is expected, it is necessary to deeply understand the limitations caused by web browser behavioral specifications and operating system power-saving features.

As explained earlier, the continuous updates of this tool's timer display rely entirely on the browser's requestAnimationFrame API, which synchronizes with screen rendering.

Standard web browsers intentionally reduce the execution frequency of this API or pause it entirely to save battery whenever the target tab becomes inactive or moves to the background.

Therefore, while the tab is in the background, the screen updates will severely delay or freeze. The moment the tab becomes active again, the process resumes and recalculates the difference, causing the display to jump immediately to the latest elapsed time.

A limitation is the behavior when the device itself enters a sleep state. When the device goes to sleep, the execution of the JavaScript program may be suspended.

When recalculating the time after waking from sleep, depending on the OS's time management mechanisms and the browser's implementation, the elapsed time during sleep might not be accurately reflected in the performance.now() calculations.

This introduces the possibility of inconsistencies or unexpected time gaps from the moment sleep started, so strict measurement accuracy is not guaranteed.

This tool is built using frontend technologies running in the browser.

Therefore, for strict continuous timekeeping spanning several hours to days, or in environments where the device might intentionally enter sleep mode, you must use this tool with the understanding that absolute precision is not guaranteed across all environments, and discrepancies or missing time may occur due to background processing limits and OS sleep states.