All solutions have problems, but I think UTC midnight is simpler than dealing with mixed date formats in the backend.

It’s 2025 and major backend stacks have domain-specific time types like LocalDate etc. Using them is the only correct and actually the simplest solution.

That’s a great question. ISO 8601 doesn’t allow timezone offsets on date-only strings.

If you were born in the US, can you buy cigarettes at 12:00 am on your 18th birthday in London?

I’ve never heard of age verification laws caring what timezone you were born in. In fact, you couldn’t even pinpoint this from many people’s ID cards. Plenty of US states span multiple time zones, and I wouldn’t be that surprised if there were a maternity ward out there sitting on a TZ line.

Simple answer is no, since your ID doesn’t have a time zone of birth on it, they have to read it as local time.

The answer is that no age related verification-problem in real world is so sensitive that a day plus or minus would make any difference. So they skip the entire clusterfuck of a problem of timezones by just ignoring them.

I grew up in a country where you could legally buy beer with 16 and and hard alcohol with 18. So if the answer to "when should someone be allowed to choose to drink alcohol" has a variance of multiple years between countries who cares about a day or two.

If you want to store a date you don't need to store a time, time zone, etc. and your question goes away.

Certainly if you want to store birth dates and do age verification there is no point bothering with these issues, just store calendar date. Trivial to get date for age limit purposes.