Format a CSV Time-Series Dataset

Time-series data is everywhere in software systems: server performance metrics sampled every minute, IoT sensor readings every second, user activity events throughout a session, stock prices at every trade. CSV is the most common format for exporting, archiving, and sharing this data between systems, and it's also one of the more demanding CSV formats to work with correctly because timestamp handling and sampling regularity are critical for correct analysis. This example shows six minutes of server performance data with five metrics per row: CPU utilization percentage, memory utilization percentage, requests per second, and error rate. The data captures an interesting incident: starting at 10:10, CPU spikes from 45% to 82% and then to 91%, requests per second jump from 142 to 634, and the error rate climbs from 0.001 to 0.041 — a classic traffic spike causing resource exhaustion. By 10:20, the metrics recover, suggesting the spike was temporary. Timestamp format is the most critical field in time-series data: the ISO 8601 format with UTC timezone (2024-01-15T10:00:00Z) is the only format that sorts correctly lexicographically, is unambiguous regardless of locale, and is natively understood by virtually every time-series database, charting library, and analysis tool. Timestamps without timezone information are ambiguous — the same file opened in New York and Berlin would produce different charts if timestamps don't specify timezone. Detecting data quality issues: gaps in time-series data are invisible when viewed as a table but catastrophic for interpolated charts. With a 5-minute sampling interval, consecutive rows should always differ by exactly 5 minutes in their timestamps. A script that checks (row[n+1].timestamp - row[n].timestamp) == 5 minutes will surface any gaps where a sample was missed, which might indicate the monitoring agent was down or the system was restarting. Anomaly patterns in this example: the error rate jumps from 0.002 to 0.012 at 10:10 (6x increase) and then to 0.041 at 10:15 (a further 3.4x increase). Cross-referencing with the CPU and request rate trends confirms this is a genuine load-related incident rather than a transient spike, which would only appear in one row. Real-world workflows: a monitoring team exports hourly metric snapshots to a data lake for long-term capacity planning; a data scientist analyzes 90 days of request rate data to identify daily and weekly traffic patterns for autoscaling configuration; an SRE team correlates deployment events with metric anomalies to identify regressions. Tips: when resampling time-series data to coarser intervals (e.g., 5-minute data to hourly averages), use mean for rate metrics and max for capacity metrics like CPU — taking the mean of CPU usage gives you average utilization, while taking the max preserves peak utilization that could indicate saturation.

timestamp,cpu_percent,memory_percent,requests_per_sec,error_rate
2024-01-15T10:00:00Z,23.4,61.2,142,0.001
2024-01-15T10:05:00Z,45.1,63.5,287,0.002
2024-01-15T10:10:00Z,82.3,71.8,521,0.012
2024-01-15T10:15:00Z,91.7,79.2,634,0.041
2024-01-15T10:20:00Z,54.2,68.1,312,0.008
2024-01-15T10:25:00Z,28.9,62.4,167,0.001