Age-gated flows fail in narrow places: the day before a birthday, the leap day, the timezone boundary. Setting a tight age range here produces a batch clustered right against whatever threshold you are testing.
What you can control
- Set the minimum and maximum age and every row lands inside it, calculated from today rather than a fixed year.
- Five output formats, including Unix timestamps for anything that stores dates as integers.
- The calculated age column accounts for whether the birthday has passed this year — the off-by-one that most age code gets wrong.
- Narrow the range to a single year to stress-test an eligibility boundary.
What this is not
Ages are calculated in UTC. A user near a date boundary in another timezone may be a day older or younger than the column says, which is itself a bug worth reproducing.
Questions
How is age calculated?
Years since the birth year, minus one if this year's birthday has not happened yet. That subtraction is the part most implementations get wrong.
Can I generate people under 18?
Yes. Set the minimum age to 0. It is the fastest way to check that an age gate actually blocks who it claims to.
Why use Unix timestamps?
Because plenty of systems store dates as integers, and rendering one back as a date is where timezone bugs surface.