About

Date truncation is the operation of zeroing all temporal components below a chosen granularity level. Truncating t to the month level sets the day to 1 and the time to 00:00:00.000. This is not rounding. Rounding considers the midpoint. Truncation always floors toward the start of the period. Confusing truncation with rounding when aggregating time-series data produces off-by-one-period errors in financial reports, billing cycles, and cohort analyses. This tool applies deterministic truncation across seven granularity levels and outputs in four formats simultaneously.

Week truncation follows ISO 8601: weeks start on Monday, and the first week of the year contains the year's first Thursday. Quarter boundaries fall on months 1, 4, 7, and 10. All calculations execute in the browser using native Date arithmetic with no timezone conversion. The input is interpreted as local time. Limitation: dates before the Unix epoch (1970-01-01) produce negative Unix timestamps, which are valid but may confuse downstream systems that expect unsigned integers.

Formulas

The truncation function trunc maps an input datetime t and granularity level g to a new datetime where all components below g are set to their minimum values.

trunc(t, g) = t − (t mod g)

For quarter truncation, the quarter-start month m_q is computed as:

m_q = floor(m − 13) × 3 + 1

where m is the 1-indexed month (1 - 12).

For ISO week truncation, the day-of-week offset δ from Monday is:

δ = (d_js + 6) mod 7

where d_js is JavaScript's getDay() value (0 = Sunday). The truncated date is then t − δ days, with time zeroed.

The Unix timestamp in seconds:

ts = floor(t_ms1000)

where t_ms is milliseconds since epoch from Date.getTime().

Variable legend: t = input datetime, g = granularity level, m = month (1-indexed), m_q = quarter-start month, δ = weekday offset from Monday, d_js = JavaScript day index, ts = Unix timestamp in seconds, t_ms = epoch milliseconds.

Reference Data

Granularity	Zeroed Components	Example Input	Truncated Output	Common Use Case
Year	Month, Day, Hour, Min, Sec, Ms	2024-07-15 14:32:09	2024-01-01 00:00:00	Annual reports
Quarter	Month (within Q), Day, Hour, Min, Sec, Ms	2024-08-22 09:15:00	2024-07-01 00:00:00	Fiscal quarter aggregation
Month	Day, Hour, Min, Sec, Ms	2024-03-17 22:45:30	2024-03-01 00:00:00	Monthly billing cycles
ISO Week	Day (to Monday), Hour, Min, Sec, Ms	2024-01-04 11:00:00	2024-01-01 00:00:00	Sprint planning
Day	Hour, Min, Sec, Ms	2024-12-25 18:30:00	2024-12-25 00:00:00	Daily log partitioning
Hour	Min, Sec, Ms	2024-06-01 14:47:22	2024-06-01 14:00:00	Hourly metrics buckets
Minute	Sec, Ms	2024-09-10 08:33:55	2024-09-10 08:33:00	Cron job alignment
Second	Ms	2024-02-29 12:00:00.789	2024-02-29 12:00:00.000	Log deduplication
Quarter Boundary Reference
Q1	January 1 - March 31
Q2	April 1 - June 30
Q3	July 1 - September 30
Q4	October 1 - December 31
ISO Week Rules
Week Start	Monday
Week 1	Contains the year's first Thursday
Max Weeks	52 or 53 (long years)
Unix Timestamp Reference Points
Epoch	1970-01-01T00:00:00Z = 0
Y2K	2000-01-01T00:00:00Z = 946684800
Max 32-bit	2038-01-19T03:14:07Z = 2147483647

Frequently Asked Questions

ISO 8601 defines Week 1 as the week containing the year's first Thursday. This means December 29-31 may belong to Week 1 of the following year, and January 1-3 may belong to Week 52 or 53 of the preceding year. This tool truncates to the Monday of the ISO week the input date falls in. If your date is 2024-01-01 (a Monday), it truncates to 2024-01-01. If your date is 2023-01-01 (a Sunday), it truncates to 2022-12-26 (the preceding Monday), because Jan 1 2023 falls in ISO week 52 of 2022.

Most SQL DATE_TRUNC('quarter', ...) functions use calendar quarters (Q1 = Jan - Mar, Q2 = Apr - Jun, Q3 = Jul - Sep, Q4 = Oct - Dec). This tool uses the same convention. Discrepancies arise when your organization uses fiscal quarters offset from the calendar year (e.g., fiscal Q1 starting in April). This tool does not support custom fiscal year offsets. For fiscal quarter work, subtract your fiscal offset months before truncating.

No. All operations use the browser's local timezone via JavaScript's Date object. The tool does not convert between timezones. If you input a time that falls on a DST boundary (e.g., 2:30 AM during spring-forward), the browser's Date constructor resolves the ambiguity according to your OS timezone rules. For UTC-critical work, input your date already converted to UTC.

JavaScript's Date object does not support leap seconds. The value 23:59:60 will be interpreted as 00:00:00 of the next day. Truncation will then produce the start of that next day at the chosen granularity. This is a limitation of the POSIX time model used by all browsers.

Yes. Dates before 1970-01-01T00:00:00 local time produce negative Unix timestamps. For example, 1969-07-20 (Apollo 11 landing) yields approximately −14,182,940 seconds. Negative timestamps are valid per POSIX, but some APIs, databases, and programming languages reject them. The tool displays both millisecond and second precision timestamps.

The output includes a "Removed" line showing the exact duration between your original date and the truncated result. For example, truncating 2024-03-15 14:32:09 to Month yields a removal of 14 days, 14 hours, 32 minutes, and 9 seconds. This helps you verify the truncation was applied correctly and quantify the precision loss.