Generate random dates and times inside any range, formatted as ISO 8601, date only, time only, Unix seconds, Unix milliseconds or a readable string. Useful for seeding test fixtures and for checking that date handling survives awkward values.
Settings
Recent results
Generated locally in your browser β your settings and results never leave this page.
Dates are where software breaks
Date handling is a reliable source of bugs, and most of them only appear with particular values. February in a leap year. The last day of a month. A timestamp at midnight, where an off-by-one in a comparison silently drops a day. Year boundaries, where a week-number calculation can place the first days of January in the previous year. Generating a spread of values across a wide range surfaces these far more effectively than testing with today’s date.
That is the practical case for a date generator: not to invent decoration for a demo, but to push a range of real values through code that is usually only exercised with whatever the clock said at the time.
Why everything here is UTC
Local time is not a well-defined function of a moment. In a zone that observes daylight saving, one hour each spring does not exist at all and one hour each autumn happens twice. Generating a local time can therefore produce a value that no clock in that zone ever displayed, or one that is genuinely ambiguous.
UTC has no such gaps. Every moment maps to exactly one representation, and every representation is a real moment. Generating in UTC and converting at the edge of your system is the same discipline that makes date handling reliable in production: store and compute in UTC, convert only for display.
The formats and where each belongs
ISO 8601 is the default because it is unambiguous and sorts as text. A list of ISO timestamps sorted alphabetically is also sorted chronologically, which is a genuinely useful property in log files and filenames. It also removes the day-first versus month-first ambiguity that makes 03/04/2026 unreadable without knowing which convention the writer used.
Unix timestamps are integers, which makes them cheap to store, compare and do arithmetic on. The distinction between seconds and milliseconds is the trap: a seconds value interpreted as milliseconds lands in January 1970, and a milliseconds value read as seconds lands tens of thousands of years in the future. Both mistakes are common enough that generating each format to test against is worthwhile.
The readable format exists for cases where a person will look at the value. It is the wrong choice for storage or transport, because parsing it back reliably is harder than it looks.
Uniform in time, not in calendar
Values are drawn uniformly across the range measured in milliseconds. A consequence worth understanding: a 31-day month receives about eleven per cent more values than a 28-day February, because it contains more time. That is the correct behaviour for simulating events that occur at a steady rate.
If you need an equal number of values per month or per weekday, that is a different requirement and a uniform draw will not produce it. Generate per period and combine, rather than drawing from the whole span and hoping the counts balance.
Sorting
Unsorted output is the right default, because independently drawn timestamps are what most simulations need. Sorting is available for the cases where the values represent a sequence β a series of log entries, a set of events on a timeline, a chart’s x-axis. Sorting happens after the draw, so the values themselves are unchanged; only their order differs.
Awkward values are the useful ones
If you are testing date code deliberately, widen the range to include a leap year and generate enough values to land on the edges. February 29th exists only every four years, with the century exception that makes 1900 an ordinary year and 2000 a leap year. Code that assumes a four-year cycle is correct until 2100, which is far enough away that the bug will be someone else’s problem β but the same assumption applied to historical dates is wrong today.
Privacy
Dates are generated in your browser. Nothing is transmitted, stored or logged.
How to use the Random Date and Time Generator
- Enter the earliest and latest dates as YYYY-MM-DD.
- Pick an output format β ISO 8601, date only, time only, Unix seconds or milliseconds, or a readable string.
- Set how many values you need and whether to sort them chronologically.
- Generate, then copy or export as CSV.
Frequently asked questions
What is this useful for?
Seeding test data with plausible timestamps, filling a chart with sample points, generating fixtures for date-handling code, and picking an arbitrary date when you need one. It is also a quick way to produce awkward values β leap days, month boundaries, year ends β that often expose bugs.
Which time zone do the results use?
All values are UTC. That avoids the ambiguity of generating a local time that may not exist or may occur twice because of a daylight-saving transition. If you need local times, convert on the way in to your own system, where you know which zone applies.
What is ISO 8601 and why is it the default?
It is the international standard for writing dates and times, in the form 2026-08-22T14:30:00Z. It sorts correctly as plain text, has no ambiguity between day-first and month-first ordering, and is what almost every API and database expects. When in doubt, it is the right format to use.
What is the difference between Unix seconds and milliseconds?
Both count elapsed time from the start of 1970 in UTC. Seconds is the traditional Unix convention and appears throughout system tooling; milliseconds is what JavaScript uses. Mixing them up produces dates around 1970 or far in the future, which is one of the most common date bugs there is.
Can I generate times without dates?
Yes β choose the time-only format. You still set a date range, because a time is drawn from a moment inside it, but the output shows only the clock portion. That is useful for populating schedules or opening-hours fixtures.
Are the dates evenly distributed across the range?
Yes. Each value is drawn uniformly across the whole span in milliseconds, so every instant in the range is equally likely. That means longer months contribute proportionally more values, which is correct β it reflects real elapsed time rather than treating every month as equal.
Why does an invalid date show an error instead of just working?
Because silently falling back to a default range would hand you dates from a period you never asked for, and they would look entirely plausible. The tool requires the YYYY-MM-DD form and says so rather than guessing.
