Whole days, not timestamps
Everything in this tool works on a day index — the count of whole days since the start of 1970, computed in UTC — and only converts back to a calendar date at the moment of printing. That sounds like an implementation detail and it is the reason the output is correct.
The alternative is to pick a random millisecond between two timestamps and let a Date object turn it into a calendar date. In a local time zone that goes wrong twice a year. On the day a clock goes forward there is an hour that does not exist, so an instant chosen inside it lands somewhere unexpected; on the day it goes back an hour repeats. Around midnight, a value that should be the 14th quietly becomes the 13th. Working in whole UTC days removes the failure mode completely: a day is a day, February 29 exists in the years it exists in and not otherwise, and the date printed is the date drawn.
What "uniform" means when there is a filter
The draw builds the full list of days in the range that pass the filter, then picks from that list. Every candidate day has exactly the same chance, and the tool prints that chance so you can check it. This matters more than it looks once a filter is on: weekdays-only over a year is roughly 261 candidates, not 365, and a naive approach of picking any day and rerolling weekends produces the same distribution but with an unpredictable number of attempts — while picking a random week and then a random weekday within it does not, because months and years do not divide evenly into weeks.
The filter for the first or last seven days of a month is calendar-aware in the same way. The last seven days of February in a leap year are the 23rd to the 29th, and in a common year the 22nd to the 28th, both handled by asking the calendar how long the month is rather than by assuming thirty.
Repeats, and the collision you should expect
Without repeats the tool shuffles the candidate list with Fisher-Yates and takes the first N, which gives a uniformly random subset with no date appearing twice. With repeats each draw is independent, and duplicates arrive far sooner than intuition suggests. Drawing 30 dates from a one-year range gives better than a two-thirds chance that at least two land on the same day — the birthday problem, with the same arithmetic that makes two shared birthdays likely in a room of 23 people.
Which one you want depends on what the dates are for. Sample rows for a test fixture usually want repeats allowed, because real data repeats. Assigning distinct slots — audit dates, inspection days, a schedule where two things must not collide — wants repeats off, and the tool will tell you when the request exceeds the number of available days rather than looping forever trying to satisfy it.
Formats, and the one that avoids arguments
ISO 8601, written year-month-day with hyphens, sorts correctly as plain text, is unambiguous everywhere, and is what to use if the dates are going into a file, a database or a spreadsheet column. The US format puts the month first and the day-first format puts the day first, and 3/4/2026 means two different days on the two sides of the Atlantic — which is exactly the bug this format choice is here to let you reproduce deliberately. The long and weekday formats are for reading rather than parsing.
Times, when you add them, are wall clock readings with no zone attached and no claim to be instants. That is deliberate: a time with a zone is a much more complicated object, and generating them without asking which zone would produce data that looks right and is wrong. If you need to move a real time between zones, the timezone converter does that, and the timestamp converter handles epoch values.
Questions people ask
Are the dates uniformly distributed?
Yes, over the candidate days that survive the filter. The tool lists every matching day between the two endpoints and draws from that list with rejection sampling, so each candidate has exactly the same probability and the figure is printed in the results for you to check. Both endpoints are included. What is not uniform is the weekday spread when a filter is on, because a filtered range simply contains more of some weekdays than others.
Why does the weekday table look lopsided?
Small samples look lopsided. Ten dates spread over seven weekdays cannot be even, and even a hundred will show a noticeable spread — an average of about fourteen a day with several days off by four or five in either direction. That is what random looks like. If the range itself is short it can also be genuinely lopsided: a 40-day window contains six of some weekdays and five of others, and the draw reflects the range it was given.
Can I get more dates than there are days in the range?
Only with repeats allowed. With no repeats requested, the draw is capped at the number of candidate days and the tool says so rather than silently repeating or looping, which is the honest failure: you cannot pick 60 distinct Mondays out of a range that holds 40. Turn repeats on, widen the range, or relax the day filter.
Do the times account for daylight saving?
No, and they are not meant to. A time here is a wall clock reading between 00:00:00 and 23:59:59 with no time zone attached, so it is not an instant and cannot be converted to one without knowing a zone. In zones that observe daylight saving there is one day a year on which some wall clock times do not exist and one on which some occur twice. The dates themselves are computed in whole UTC days and are never affected by any of that.
Is this suitable for generating fake personal data?
It is fine for test fixtures, sample rows and demo screenshots, which is what most people want random dates for. Be careful about one thing: a random date of birth combined with other generated fields can look like a real record, and generated data that leaks into a production database or a shared document tends to get treated as real later. Label test data as test data at the point you create it, not afterwards.