Start & end Unix
Epoch Bounds
Unix seconds for the start and end of a UTC day, month, and year.
Epoch bounds
Pick a calendar date.
Epoch bounds prints Unix timestamps for the first and last second of a UTC day, the UTC month that contains that day, and the UTC year that contains that day. Pick a calendar date. The page does not decode a single mystery integer from a log line; that job belongs on the Unix timestamp converter. Bounds exist so a query, partition, or cache key can say “everything whose epoch second is greater than or equal to start and less than or equal to end.”
Start second and last second
Day start is 00:00:00 UTC on the picked date, as integer seconds since 1970-01-01 00:00:00 UTC. Day end is 23:59:59 UTC on that date, which is the first second of the next date minus one. The range is inclusive of the last second. Filters written as end exclusive (less than next midnight) should use next day’s start instead of this last-second value, or they will drop events in the final second or double-count if mixed with inclusive code.
Month start is 00:00:00 UTC on day 1 of that month. Month end is 23:59:59 UTC on the last civil day of the month. Year start is 1 January 00:00:00 UTC. Year end is 31 December 23:59:59 UTC. February in a leap year makes the month-end second later by 86400 than in a common year; the year-end second moves by the same extra day. The leap year rule is applied through the JavaScript Date.UTC constructor, not by a handwritten 365 table.
All six numbers are UTC. They are not “midnight in New York.” A US/Eastern log that stores local midnights will not match these integers. Convert local midnights with a zone-aware encoder first, or accept that a UTC day is a different slice of the timeline than a Chicago day.
Why a single-instant converter is the wrong tool here
Pasting one epoch into the Unix converter tells you which civil instant that integer is. It does not tell you the other edge of a bucket. Analysts who type “1 January 2026” into a datetime picker and encode once get the start, then guess the end by adding 86400 and missing 23:59:59 versus 00:00:00 off-by-one bugs. This page prints both edges so the guess goes away.
Month and year buckets are worse to guess because month lengths differ. Adding 30 × 86400 to a month start lands in the wrong month often. Adding 365 × 86400 to a year start is wrong in leap years. Reading month-end and year-end here is faster than re-deriving calendar arithmetic in a SQL window.
Millisecond and nanosecond columns still need scaling. These bounds are whole seconds. If the database stores milliseconds, multiply start by 1000 and use next-bucket start times 1000 minus one for an inclusive millisecond end, or store exclusive ends. Do not append “999” by folklore without documenting unit scale.
Query and partition patterns
A typical SQL pattern is WHERE ts >= day_start AND ts <= day_end for inclusive seconds, or ts >= day_start AND ts < next_day_start for exclusive ends. Mixing the two styles in one report duplicates or drops the 23:59:59 row. Pick one convention in the runbook and generate numbers to match it. This UI follows inclusive last second because people ask for “end of day” in words.
Object-storage prefixes and analytics partitions often use the date string (YYYY-MM-DD) rather than epoch edges. When a legacy job still filters on integer seconds, copy the six numbers into the ticket. When a new job can filter on date, prefer ISO dates and leave epoch bounds for interoperability with APIs that only speak POSIX seconds.
Redis sorted sets, Kafka timestamps, and JWT NumericDate fields are usually seconds or milliseconds at one instant, not a range. Use the single-instant converter for those. Use this page when a job must sweep a whole UTC day, month, or year of second-granularity events.
Worked bound examples
Pick 1 March 2026. Day start is midnight UTC on 1 March. Day end is 23:59:59 that day. Month start equals that day start, because the picked day is the first. Month end is 23:59:59 on 31 March. Year start is 1 January 00:00:00 UTC of 2026. Year end is 31 December 23:59:59 UTC of 2026.
Pick 31 December. Day and year-end last seconds coincide. Month-end for December coincides with year-end. That triple equality is a useful QA check: if those three “end” integers disagree, the implementation is wrong.
Pick 29 February in a leap year. The day exists and has a start and end. In a common year the browser date control will not offer 29 February; do not paste an invalid date string. For month-end of February in a common year, pick any February day and read month end—it will be 28 February 23:59:59 UTC.
Leap seconds and 32-bit clocks
POSIX Unix time usually repeats or skips a second label around leap seconds rather than representing 23:59:60. These bounds assume 86400 labeled seconds per civil day. They are correct for ordinary software clocks and wrong as a physical SI-second meter on a leap-second day. Systems that smear leap seconds still expose 86400 labels; the smear lives inside the second.
Signed 32-bit Unix overflow is a storage problem for the integer type, not a reason to avoid printing year-end bounds for 2026. If a column is still int32, test whether the year-end integer still fits; if not, migrate the column. That migration is not this page’s arithmetic.
Other epochs belong on other converters: FILETIME (100 ns from 1601), NTP (seconds from 1900), and GPS/TAI scales. Do not feed those integers into a Unix bounds filter.
Related tools
Single instant: Unix timestamp. Windows 1601 clock: FILETIME converter. Other encodings: converters hub.
Frequently asked questions
What Unix values does this page print for a chosen UTC day?
It prints the Unix second at 00:00:00 UTC and at 23:59:59 UTC for that date, plus the same pair for the containing UTC month and UTC year. All six numbers are whole seconds since 1970-01-01 00:00:00 UTC. They are bounds for a range query, not a decode of one mystery log integer.
How is the last second of a month or year defined?
The last second is 23:59:59 UTC on the last civil day of that month or year, equal to the next month’s or year’s start minus one second. Inclusive filters should use that integer as the end. Exclusive filters should use the next bucket’s start and the operator less-than, or the final second will be dropped or double-counted.
Why use bounds instead of converting a single instant?
A single Unix converter tells you what one integer means. It does not give the other edge of a day, month, or year bucket. Guessing the end by adding 86400, 30 days, or 365 days breaks on month length and leap years. This page prints both edges so partition jobs do not invent calendar math.
Is the range computed in local time or always UTC?
Always UTC. Midnight in a US time zone is a different Unix second than 00:00:00 UTC. If a log stores local midnights, encode those with a zone-aware tool before comparing. Mixing UTC day bounds with Eastern-time partitions will shift events near midnight across the wrong bucket.
When should a log query use the month-start Unix second?
Use month start when the job must sweep every event in that UTC month, such as a billing period stored as POSIX seconds. Combine it with month end (inclusive) or next month start (exclusive). APIs that already filter on an ISO date string do not need these integers; keep epoch bounds for integer-only interfaces.
How do leap days affect the year-end Unix bound?
In a leap year the UTC year contains 366 civil days, so year end (31 December 23:59:59 UTC) is 86400 seconds later relative to 1 January than in a common year. February’s month-end last second also moves from the 28th to the 29th. The page uses Date.UTC rather than a fixed 365-day table.