undefined | Better HN

0 pointsnames_are_hard10mo ago0 comments

What if you're storing a calendar date, such as a birthday? A timestamp is inappropriate, and it's meaningless to discuss timezones in this context.

(Example - you want to know if a person is old enough to buy cigarettes, and you need to store a birthday that you can compare against the current day to see if they're legally 18 - if you store an epoch at UTC, do you store the time of day they were born? That's not the way the law works. Do you store midnight UTC? If they're currently in NY, can they but cigarettes at 7pm the day before their birthday because they're currently 18 in London?)

Sometimes you need a logical calendar date, not a point in time in the history of the universe.

0 comments

guffins10mo ago

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.

atoav10mo ago

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.

ezfe10mo ago

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.

rubslopes10mo ago

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

ivan_gammel10mo ago

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.

mytailorisrich10mo ago

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.

j / k navigate · click thread line to collapse